Whatever you want to call them, my point is that most languages, including Rust, don’t have a way to define new integer types that are constrained by user-provided bounds.

Dependent types, as far as I’m aware, aren’t defined in terms of “compile time” versus “run time”; they’re just types that depend on a value. It seems to me that constraining an integer type to a specific range of values is a clear example of that, but I’m not a type theory expert.

It sounds like you’re talking about dependent typing, then, at least for integers? That’s certainly a feature Rust lacks that seems like it would be nice, though I understand it’s quite complicated to implement and would probably make Rust compile times much slower.

For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check.

That’s exactly what I described above. By default, trapping on overflow/underflow is enabled for debug builds and disabled for release builds. As I said, I think this is a sensible behavior. But in addition to per-operation explicit handling, you can explicitly turn global trapping behavior trapping on or off in your build profile, though.

It depends what kind of errors you’re talking about. Suppose you’re implementing retries in a network protocol. You can get errors pretty regularly, and the error handling will be a nontrivial amount of your runtime.

By Ada getting it right, I assume you mean throwing an exception on any overflow? (Apparently this behavior was optional in older versions of GNAT.) Why is Ada’s preferable to Rust’s?

In Rust, integer overflow panics by default in debug mode but wraps silently in release mode; but, optionally, you can specify wrapping, checked (panicking), or unchecked behavior for a specific operation, so that optimization level doesn’t affect the behavior. This makes sense to me; the unoptimized version is the same as Ada, and the optimized version is not UB, but you can control the behavior explicitly when necessary.

There’s also a massive tradeoff for when the error condition actually occurs. If an exception does get thrown and caught, that is comparatively slowwww.

I mean, at least you acknowledge that you’re presenting an opinion. This blog post just tries to gloss over the fact that it’s pure speculation.

I was hoping this might start with some actual evidence that programmers are in fact getting worse. Nope, just a single sentence mentioning “growing concern”, followed by paragraphs and paragraphs of pontification.

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.