I completely agree that requests are what should be charged for. But I think there are two things, given that requests aren't all going to cost the same amount:
1. Estimate free invoicing the requests and letting users figure it out after the fact.
2. Somehow estimating cost and telling users how much a request will cost.
im fiarly certain the knob on the machine that controls length of redundant comments and docblocks is cranked to 11. it makes me curious how much of their bottom line is driven by redundant comment output.
I think it's funny and interesting how LLMs are commoditizing information generation. It's completely expected, but also somewhat challenging to figure out what the best combination of "learning" "fact" systems is.
I'd be curious to know more about how this compares to other approaches.
My #1 issue with Neovim is the new ! Behavior. Anyone know how to make it toggle the alt terminal screen and just output to the primary screen like it does in Vim?
I understand the annoyance, but my workflow for years has been running (n)vim in tmux. So I never need to run terminal commands from the editor, that’s what other tmux panes/windows are for.
The new ! just isn't as useful, and it's harder to get back to see the outputs. The old ! Was just a drop in way quickly do something like ctrl-z command fg.
I don't think explicit naming of impls is wise. They will regularly be TraitImpl or similar and add no real value. If you want to distinguish traits, perhaps force them to be within separate modules and use mod_a::mod_b::<Trait for Type> syntax.
> An interesting outcome of removing coherence and having trait bound parameters is that there becomes a meaningful difference between having a trait bound on an impl or on a struct:
I don't think fully-qualified paths are enough on their own. You also need some way to designate that an impl is symbolically unique and has to be referred to by path. Otherwise, you still end up with a problem where the compiler doesn't know which implementation to use unless you precisely name it.
You depend on crates A and B. A impls Foo for Bar. You pass an instance of Bar to a function that accepts `impl Foo`. You are happy. Later crate B adds an impl of Foo for Bar. Clearly _at least_ one of these must be an orphan impl, but both could be. Suddenly it's ambiguous which implementation of Foo you're talking about, so you break because B added an impl.
There are many potential problems of this flavor with letting any `impl Trait for Type` be an orphan impl and then referenced by path. What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?
I think there has to be special syntax for named/path-referenced/symbolic impls, even if the impl does not have an identifier name, so that the compiler can know "this impl only resolves if you tell me _specifically this impl_" and the impl provider has a way to create a solid consumer contract about how to use that impl in particular.
Also, not having an identifier name would mean you can't have different impls of Foo for Bar in the same module. That's probably not a limitation anyone would care about, but it's there.
Using the mod name would give it a unique name, just implicitly through the module, so I don't see the issue, unless you wanted to allow a single module to allow multiple impls of the same item.
I also don't see an issue with having multiple impls of the same trait, as long as they don't provide duplicate items inside a module. I often do multiple impl blocks to break up larger logic and organize docs, though this is generally not for trait impls, but I don't see why it couldn't be.
Let me be clear though, I'm not saying this is the best path forward on the coherence/orphan situation necessarily, just a minor critique of the blog posts position. This is a famously tricky issue, and I suspect there is no silver bullet here. Though I have always wanted some way to add flexibility to the orphan rule.
> You depend on crates A and B. A impls Foo for Bar. You pass an instance of Bar to a function that accepts `impl Foo`. You are happy. Later crate B adds an impl of Foo for Bar. Clearly _at least_ one of these must be an orphan impl, but both could be. Suddenly it's ambiguous which implementation of Foo you're talking about, so you break because B added an impl.
I think that's fine. Same as what happens if B adds a new function with the same name as a function in A that you were using unqualified.
> What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?
It's comical how much time I've spent convincing people that tabs are a window manager feature not an application feature. People in the Alacritty issue on the subject were pissed!
I've heard this a lot on HN over the years but it doesn't make much sense to me. Some thoughts:
1. App tabs improves UX for 99.999% of users who aren't using a WM with a good tab solution (if one even exists).
2. WM tabs means launching a new app instance for every tab you might want vs having lightweight app tabs.
3. App tabs can do all sorts of app-level things and UX polish that dumb WM tabs can't do because they are so general. My terminal emulator tabs show a badge count of bell notifications, can be dragged around into groups, or dragging into other tabs as split panes. My browser tabs show you which tab is playing music and can impl right click -> mute.
4. I bet even the biggest WM tab cheerleader still uses browser tabs.
5. WM tabs are a different concern than app tabs, not a replacement. WM tabs are useful when you want tabs and the app doesn't provide a good tab metaphor or when you want to tile/group app instances a certain way. That doesn't mean it's not useful for the app instances themselves to have app tabs when it makes sense.
Agree on all the points, except 4. There are even people out there who use lynx as their primary browser :)
Although while I usually like tabs for most apps, I don't use tabs for terminal and rely either on window manager or tmux. I guess the difference is that I often want a mix of tabs and having multiple terminals side by side, whereas I don't really need that for a browser (or very seldom)
Sway had the better, though often tedious, WM tab solution that I've tried. Niri had a useless one.
I really tried to love sway splits and tabs for terminal windows. But I finally admitted I'd rather just alt-tab to a few different terminal apps, each with its own concern (maybe one per project, this one for my remote machine), and best of all, each with its own internal tabs.
That said, tabs in kitty and tmux, for example, are so basic that you don't necessarily lose much if you were to use WM tabs instead.
On the other hand, tabs in iTerm2, Ghostty, Cmux, probably macOS Terminal -- a bit more powerful and intuitive since you can do things like drag them, and they can show info like terminal state. And in some of those apps, they can be displayed vertically which is my favorite.
My favorite is still AwesomeWM, although I haven't used it in years. Nowadays I'm on mac and my "tiling manager" is about 6-7 custom functions I wrote in hammerspoon. Basically just tile left/right, full size, "reasonable" size + centered, and a shortcut that distributes all my apps in the virtual spaces I've assigned to them.
One of the reasons why I use tmux rather than i.e. iterm2 tabs is that I don't have to change any of my habits or learn extra shortcuts when I'm working with ssh.
I would love tabs for Spotify. I just discovered I can at least open new windows from the linux YouTube music client by middle clicking, a revelation !
Every application (or concept) can introduce “tabs”, but it means something wildly different for that particular application. Tabs (or instances) in an application immediately bumps into the concept of state (statefull vs stateless) in applications.
Sometimes, it makes perfect sense. The reason tabs made sense for web browsers since 2004 is because each web page could be thought of as a “stateless” instance of an application. You’re not asking for “tabs”, you wish every application could be “Stateless”. Stateless is a beautiful thing, until you understand what state is, and who needs to manage it.
If every “tab” of Spotify had no idea what the other “tab” is playing and you had to switch back and forth between tabs to pause-and-play songs, that would be a bug, not a feature. While 2 “windows” playing audio (if you instruct them to) is expected.
And if the surprise is unpleasant you can disable it by turning off memories and holidays in the settings of the photo app. Not so easy to escape Copilot on Windows.
That's not nearly comparable tho. I don't care it's watching my photo as long as it doesn't annoy me when I want to watch them. Copilot is everywhere, you got to actively avoid it like the plague it is.
Even the linked blog post indicates that that is not the case. Windows has Copilot buttons on practically every built in application, a taskbar icon, and a dedicated physical keyboard key that people commonly accidentally hit (contractually required for OEMs to provide). They also actively promote Copilot in the OS (particularly Home Edition with nothing disabled e.g. "Tips," Notification Spam, Recommendations, etc).
Nobody can predict what Apple will do tomorrow, but as of today, they aren't really pushing Siri/Apple intelligence really hard particularly after initial setup. None of most of the above for example.
I have Pro Edition and for me Copilot only added two icons. One in Notepad and another one in Paint. I ignore both. There's also the Copilot app that I didn't even know I have installed.
I don't know what happens with Home Edition, but I though the pushback was mainly from Insider Preview?
You want to take a look at Microsoft office, my bad Microsoft copilot 365...
You can't even select a cell on notepad without a freaking copilot button pooping up every single time. Same on word, that's maddening !
You could argue that windows isn't Microsoft copilot 365, but then, why do people even use windows ? It's always because of the office, my bad, copilot 365 suite.
You can also get rid of both of them very easily with O&O Shutup 10++ (or any of many other GUIs or scripts designed for the same purpose of decrapifying Windows). I toggled off Copilot and Onedrive and haven't seen either in all the years I've been using Windows 11.
I'm not GP, so I can't comment on where their line is, but for me the difference between Copilot and Apple Intelligence is that I can turn off the latter and never see anything about it again. Copilot, on the other hand, is everywhere and it's almost all universally buggy garbage, even when it's disabled.
I actually trust the Apple Intelligence, when off, doesn't exfiltrate my data.
Oh yeah and even when you turn off preferences/settings/features in Windows, they mysteriously come back later in one of the unilateral forced updates, against your wishes.
> So the issue isn't actually that it's baked into the OS, it's that you should have control over when it's used.
Baked into the OS implies that it's integral to its operation in a way that the two are fundamentally inseparable. Having a global off switch implies that's not true.
There are other irritating baked in aspects of the newest macos and other recent versions that are arguably less avoidable, like Tahoe's entire UI design, or the Settings app.
The real issue is copilot is implemented in their apps inconsistently. Very clear there’s little cross app planning. Apples solution is global and apps and hook into it or not. And if you turn it off apps done break.
Why would Apple Intelligence bother them? It's very unobtrusive and actually useful when it's visible. I literally don't notice it except when it's helpful.
I don’t think I’ve ever even noticed Siri/Apple intelligence on macOS. I’ve disabled it somehow (probably at install) and have not heard about it since
Have you even tried it? I'm a Mac user for 20+ years and I'm running Tahoe. Not once have I ever thought about Apple Intelligence. I don't even notice it. I think you have to switch it on.
Nobody ever wanted to wire up RPC endpoints, in the form of Enterprise JavaBeans(tm), using XML files. That is one for the history books of ridiculous technology.
XML files are bad. Invisible magic is worse. The sensible way to wire up a bunch of RPC endpoints is, like the sensible way to do most things, plain old code.
This blog post makes no sense to me.
reply