Expurple

You can `cargo clean --workspace` now, to avoid rebuilding the dependencies

In pushback against “Stop Forwarding Errors, Start Designing Them” [1]

[1]: https://fast.github.io/blog/stop-forwarding-errors-start-des...

Sure. But any nontrivial C codebase will have UB regardless of your intentions. This has been proven time and time again.

But are they "no UB in the code" great? For my use, Opus is absolutely good enough at Rust

Yeah, it's almost always more effective to work with an existing project as a starting point

> that's probably due to the lack of a stable ABI complicating dynamic linking enough to make LGPL less viable

They could use MPL. It's an alternative "weak copyleft" license that's not concerned with dynamic linking

> 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.

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.

> you can still ignore the return value

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.

That's simply an implementation/ABI issue. See https://github.com/iex-rs/iex/

Language semantics-wise, Result and `?` are superior to automatically propagated exceptions.

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.

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

How would you implement a C++ ban in Chromium?

You should compare exceptions to Result-style tagged unions in a language with exhaustiveness checks, like Rust. Not to return codes in C, lmao.

Everyone (except Go devs) knows that those are the worst. Exceptions are better, but still less reliable than Result.

https://home.expurple.me/posts/rust-solves-the-issues-with-e...

> advice: submit the binary you used to generate the site to source control.

Or use HVM and submit the .hvm file (which is just a text file with the Hugo version that you use)

You don't need a test suite. Your website is the test suite. You can build it with an old version of Hugo, build it with a new version of Hugo, and then diff the output folders: https://home.expurple.me/posts/fearless-website-updates-with...

Why not donate to gnome or kde to improve those directly?

> 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.