But "drop-in replacement"? That's a strong and specific claim.

I do actually think that WebAssembly will enable something - maybe Rust, but more likely something simpler - to eventually dethrone JS in the browser. I also do think it seems beneficial to have your client and backend in the same language.

What macros or attributes provide serialization in C++?

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.

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.

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.

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.

I don't know, but I also don't know how much you think is "enough" to deal with project cultural issues. It sounds like it must be quite a bit?

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.

The phrasing "available on servers" does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.