Oh. Well, in that case, his resignation message was pretty matter-of-fact, not dramatic. He did link, in a note at the end of the email, to the now-infamous “the fact is, you’re not going to force everyone to learn Rust” video, and the drama was more or less self-manufacturing from there. But to be honest, I think it’s a good thing that more people are seeing that video than otherwise would have, and I can’t really blame him for linking to it.

And isn’t it somewhat concerning that bringing Rust to the kernel is still so controversial and highly “political”, several years after initial approval by Linus and Greg KH?

Ah, sorry, I misinterpreted your comment somehow. Yes, Rust is bootstrappable today, it’s just a much longer process than it would be if there were a compiler written in C.

You cannot, today, build a Rust compiler directly from C, but you’re right that people are working on it. See this recent post: https://notgull.net/announcing-dozer/

Edit: you can certainly bootstrap Rust from C via C++, as the article covers. I misinterpreted the comment above.

He spent four years as the project maintainer. That’s hardly “flouncing off.”

It would be a valid point if he weren’t literally speaking over the people trying to tell him that they’re not demanding he learn Rust: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548

Oh jeeze, you have no idea. You can watch it yourself: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548

That timestamp is about where the audience member (a maintainer of ext4 and related utilities) starts speaking. The “here’s the thing” quote is around 28:40.

The goal is rather to not need to think as hard…

Or, if one prefers, having more flexibility to choose how and where to allocate mental energy, rather than letting the language force you to spend some amount on the “bookkeeping” necessary to avoid various footguns.

Yeah, I mean, I tried to be explicit that I wasn’t recommending unity builds. I’m just pointing out that OP, while misinformed and misguided in various ways, isn’t actually wrong about header files being one source of slowness for C++.

You don’t need to do any of those things with Go or Rust. Interfaces/traits provide the capability for dynamic dispatch.

Slow compared to just chucking everything into a single source file, actually: https://github.com/j-jorge/unity-build

That’s only true for clean builds and even then isn’t universally true, and of course there are other reasons not to do unity builds. But the existence of the technique, and the fact that historically it has sped up build times enough for various projects to adopt it, does show that the C++ model, with headers and separate compilation units, has some inherent inefficiency.

These are extremely superficial observations. You should learn more about each of these languages before dismissing them; Go is especially easy to learn.

(I quite dislike Go, actually, but “it has no classes” is nowhere near a valid reason not to learn a language.)

OP clearly means “preprocessor”, not “precompiler”. You’re right that preprocessing itself isn’t slow, but the header/impl split can actually cause some slowness at build time.

Yes, popular programs behave correctly most of the time.

But “perfectly fine for the last two decades” would imply a far lower rate of CVEs and general reliability than we actually have in modern software.

First and foremost _____ is a giant hack to mitigate legacy mistakes.

Wow, every article on web technology should start this way. And lots of non-web technologies, too.

Take a step back and look at the pile of overengineered yet underthought, inefficient, insecure and complicated crap that we call the modern web…

Think about how many indirections and half-baked abstraction layers are between your code and what actually gets executed.

Think about that, and then…what, exactly? As a website author, you don’t control the browser. You don’t control the web standards.

I’m extremely sympathetic to this way of thinking, because I completely agree. The web is crap, and we shouldn’t be complacent about that. But if you are actually in the position of building or maintaining a website (or any other piece of software), then you need to build on what already exists, unless you’re in the exceedingly rare position of being able to near-unilaterally make changes to an existing platform (as Google does with Chrome, or Microsoft and Apple do with their OSes) or to throw out a huge amount of standard infrastructure and start as close to “scratch” as possible (e.g. GNU Hurd, Mill Computing, Oxide, Redox OS, etc; note that several of these are hobby projects not yet ready for “serious” use).

If you think anything in software has worked “perfectly fine for the past two decades”, you’re probably not looking closely enough.

I exaggerate, but honestly, not much.

Yeah, that part is pretty wild and definitely Microsoft’s fault.

The Crowdstrike problem was in fact a Crowdstrike problem. It affected Linux too, but of course there are vastly fewer users of Crowdstrike on Linux: https://www.google.com/amp/s/www.theregister.com/AMP/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

This is pretty obviously a Microsoft problem.

What were the issues you’ve had with WSL? I’ve been happily using that for a while now.

I hear you, but here’s my experience:

I’ve had one coworker whose personal coding style actually somewhat resembled that in the Clean Code examples. He wrote functions as small as possible, used many layers of abstraction, and named everything very verbosely and explicitly.

Now, to be fair, I don’t think he did that because of Clean Code, and he also didn’t follow most of the good practices that Martin recommends. Most egregiously, he almost never tested things, even manually (!!). He once worked an entire weekend to finish something that I needed for my part of the project, and when he was done, it didn’t work, because he hadn’t actually run it at any point (!!!).

But even when his software did work, it was horrendous to navigate and modify, specifically because of that style of writing code. I know, because when he retired, I was the only person on the team who could deal with it, so his part of the project fell entirely on me.

Now, I’ve also had to work with code that had the opposite problem: short names, no abstraction. And a sort of “worst of both” codebase where the functions were exceedingly long and full of near-duplicate functionality, but overall there was a fair amount of modularity and abstraction.

But in my opinion, it was much harder to deal with the code that hid all of its weirdness behind layers and layers of abstractions, despite those abstractions being carefully documented and explicitly named.