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