Expurple

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.

Technically, Safari is a bigger competitor than Firefox, and it's actually independent from Google. But it's not like it's better for the user...

If I understand correctly, Redis-the-permissive-project wasn't threatened by any proprietary fork. What happened is that the financials of its original authors were threatened by AWS hosting Redis as a service. It's not the same as a modified proprietary fork becoming more popular than the original.

Redis was relicensed as "source available", and then that license change led to a fork. But the most prominent fork isn't proprietary. It's a permissive one, called Valkey: https://news.ycombinator.com/item?id=44653130. That's actually a good example of an in-demand permissive project changing maintainers and staying relevant under a permissive license.

An interesting thing to see in the future is whether Redis ("source available" + AGPL) or Valkey (permissive) "wins" in the long term.

Too lazy to google the details regarding the other projects.

> I have yet to see any compelling examples.

This thread has eventually changed my own stance on permissive licenses. Now I think that LGPL/MPL have the best survival characteristics: https://news.ycombinator.com/item?id=44657017

> Can you list a few of the examples you had in mind?

As I think about it, I see that I wrote "plenty of examples" mechanically (pulled it out of my ass). Sorry :)

That entire argument of mine is stupid because it hinges on the ability to see alternative universes:

> if the original project had been permissively licensed, this wouldn't have happened

I could pull any unpopular GPL project as an "example" (that would be more popular with a permissive license because "trust me, bro"). But that's a bad argument.

Ok, I have thought more about the topic. You're right. LGPL/MPL have amazing survival characteristics. Probably better than those of permissive licenses. See my other comment: https://news.ycombinator.com/item?id=44657017

Ok, I have thought more about the topic. I was too concerned with "theory" in the above comment. Disregard it.

Web engines are a huge practical example in favor of MPL/LGPL. They suggest that MPL/LGPL may indeed have the best survival characteristics.

Companies love proprietary browsers. If there were a good-enough permissive web engine, a proprietary fork would happen and "win", even if as "a set of patches" on top of a permissive base maintained by the community for free. Luckily, the creators of FOSS web engines seem to have understood that and chose MPL/LGPL. This goes against the article.

Companies love proprietary browsers. They will never contribute to a GPL web engine. That's why we don't have any good GPL web engines. This supports the article.

Companies love proprietary browsers. Microsoft was one of the first movers on the web. They had the chance to create a competitive proprietary web engine from scratch. It was popular for a few decades. But eventually Microsoft gave up and adopted Chromium instead. Presumably, to reduce maintenance costs. It doesn't seem like their proprietary engine gave them any competitive advantages that would be worth the cost. This supports the article.

So, the article is correct regarding GPL and proprietary, even (indirectly) predicting the continued absence of GPL web engines and the death of proprietary web engines. In 2015, when the article was written, IE was still bigger than Firefox and Safari on the desktop: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

But the article completely misses the huge success of MPL and LGPL. You are 100% correct.

That's a good counterexample! If you don't need to maintain the code, then a proprietary fork has no maintenance cost and will be preferred.

I guess, the atricle still stands where you need to maintain the code.

> the linux kernel is good evidence against it.

To quote my other comment:

> I wasn't there, but the narrative online seems to be that Linux won due to its strong momentum and the leading position that it established back in the 90s, while the BSDs were held back by the AT&T lawsuit. Due to this leading position and the network effect, using and contributing to Linux is simply much more cost-effective. Privately forking a BSD and making it "better" than Linux would give you a competitive advantage, sure. But it's a prohibitively expensive thing to do.

> In other words, it's a historical accident that there was no strong BSD alternative when Linux was picking up steam. Now it's too big to fail, and the GPL works in full force. GPL can't work in full force in the early stages of a project.

I wasn't there, but the narrative online seems to be that Linux won due to its strong momentum and the leading position that it established back in the 90s, while the BSDs were held back by the AT&T lawsuit. Due to this leading position and the network effect, using and contributing to Linux is simply much more cost-effective. Privately forking a BSD and making it "better" than Linux would give you a competitive advantage, sure. But it's a prohibitively expensive thing to do.

In other words, it's a historical accident that there was no strong BSD alternative when Linux was picking up steam. Now it's too big to fail, and the GPL works in full force. GPL can't work in full force in the early stages of a project.

A good example of this pull towards cheaper maintainance is Microsoft eventually replacing its proprietary web engine with Chromium.

Although, as I've noted in the other comment, that wouldn't happen if Chromium was permissively licensed. It happened because its partially LGPL/MPL, and thus you can't create a proprietary fork (but can still use it in a proprietary browser like the new MS Edge). It seems like somethimes LGPL/MPL have the best survival characteristics

As I think about it, the article has actually predicted the death of proprietary web engines used in Internet Explorer and MS Edge Legacy!

According to Wikipedia, in 2015 IE was still bigger than Firefox and Safari (on desktops) [1]. I should've googled the stats before saying that the situation in 2015 was similar to today.

[1]: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

No, I can't remember any dead proprietary forks that would support that idea.

But somewhat, I can't remember any counterexamples either. I mean, a proprietary fork killing the permissive original. I can only remember:

- AppGet vs WinGet. But that's one permissive program killing another.

- The proprietary build of VSCode. But it's basically "a set of patches" on top of a still-maintained permissive base. And its popularity is at least somewhat dependent on the existence of that permissive base.