> I can ask copilot to build my project and verify tests results, but [..] added value is almost none.
The added value is that it can iterate autonomously and finish tasks that it can't one-shot in its first code edit. Which is basically all tasks that I assign to Copilot.
The added value is that I get to review fully-baked PRs that meet some bar of quality. Just like I don't review human PRs if they don't pass CI.
Fully agree on IDEs, though. I absolutely still need an IDE to iterate on PRs, review them, and tweak them manually. I find VSCode+Copilot to be very good for this workflow. I'm not into vibe coding.
This. If you use a modern frontier model like Opus 4.5, there's nothing to learn. No special prompting techniques. You give it a task, and most of the time it's capable of solving a big chunk quickly. You still need to babysit it, review its plan/code and make adjustments. But that's already faster than achieving the same results manually. Especially when you're at low energy levels and can't bring yourself to look into a task and figure it out from zero.
> Now they have a profit motive for slowing down the normal service.
Sure. But for now, this is a competitive space. The competitors offer models at a decent quality*speed/price ratio and prevent Anthopic from going too far downhill.
Actually, as I think about it... I don't enjoy any other model as much as Opus 4.5 and 4.6. For me, this is no longer a competitive space. Anthropic are in full right to charge premium prices for their premium product.
Rust is better here (by a lot), but you can still ignore the return value. It's just a warning to do so, and warnings are easily ignored / disabled. It also litters your code with branches, so not ideal for either I-cache or performance.
The ultimate ideal for rare errors is almost certainly some form of exception system, but I don't think any language has quite perfected it.
Only when you don't need the Ok value from the Result (in other words, only when you have Result<(), E>). You can't get any other Ok(T) out of thin air in the Err case. You must handle (exclude) the Err case in order to unwrap the T and proceed with it.
> It also litters your code with branches, so not ideal for either I-cache or performance.
Anyhow erases the type of the error, but still indicates the possibility of some error and forces you to handle it. Functionality-wise, it's very similar to `throws Exception` in Java. Read my post
Poor man's checked exceptions. That's important. From the `?` you always see which functions can fail and cause an early return. You can confidently refactor and use local reasoning based on the function signature. The compiler catches your mistakes when you call a fallible function from a supposedly infallible function, and so on. Unchecked exceptions don't give you any of that. Java's checked exceptions get close and you can use `throws Exception` very similarly to `anyhow::Result`. But Java doesn't allow you to be generic over checked exceptions (as discussed in the post). This is a big hurdle that makes Result superior.
No, it's not quite the same. Checked exceptions force you to deal with them one way or another. When you use `?` and `anyhow` you just mark a call of fallible function as such (which is a plus, but the it's the only plus), and don't think even for a second about handling it.
Checked exceptions don't force you to catch them on every level. You can mark the caller as `throws Exception` just like you can mark the caller as returning `anyhow::Result`. There is no difference in this regard.
If anything, `?` is better for actual "handling". It's explicit and can be questioned in a code review, while checked exceptions auto-propagate quietly, you don't see where it happens and where a local `catch` would be more appropriate. See the "Can you guess" section of the post. It discusses this.
I don't think the problem is the money. Neither of them provides a long term stable API, let alone ABI. So progress gets reset on a regular base.
Gnome is further hampered by no respect for user choice. They provide an appleish UI, with an Enterprise, one size fits all experience.
KDE is better, but they are not the official GNU/Red Hat choice. They will choose practical above esthetica.
A big part of the Linux success is POSIX, a standard to provide direction. The UI world never had anything line it, so it is very fragmented. A real solution could be a complete enough UI standard, used by OSX, Windows, Gnome and KDE.
> don't need a backend unless for social sharing reasons
Sync between devices is a compelling reason to have some backend. But I prefer it the way Super Productivity does it: integrating a bunch of third-party storage services like Dropbox. Usually, you already use one anyway
Unlike Firefox, Safari has another huge corporate backer (Apple). Apple is drowning in cash. They don't need Google's money to keep developing Safari. It's "just" a good, low-effort deal for them. Apple doesn't have a competing search engine, or an intention to develop one, or an intention to promote a free web and "save" their users from a search engine monopoly.
The added value is that it can iterate autonomously and finish tasks that it can't one-shot in its first code edit. Which is basically all tasks that I assign to Copilot.
The added value is that I get to review fully-baked PRs that meet some bar of quality. Just like I don't review human PRs if they don't pass CI.
Fully agree on IDEs, though. I absolutely still need an IDE to iterate on PRs, review them, and tweak them manually. I find VSCode+Copilot to be very good for this workflow. I'm not into vibe coding.
reply