> Someone in the thread said he has 30 years experience in programming, and the only new lang which is really close to C in speed is Rust.
He has a point. Both C and release-mode Rust have minimal runtimes. C gets there with undefined behavior. Rust gets there with a very, very robust language definition that allows the compiler to reject a lot of unsafe practices and make a lot of desirable outcomes safe and relatively convenient.
However, Rust also allows certain behavior that a lot of us consider undesirable; they just define the language so that it's allowed. Take integer overflow, for instance https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... . In debug mode, Rust panics on integer overflow. Good. In release mode, it wraps as two's complement. Bad. I mean, it's in the language definition, so fine, but as far as I'm concerned that's about as bad as the C https://stackoverflow.com/a/12335930 and C++ https://stackoverflow.com/a/29235539 language definitions referring to signed integer overflow as undefined behavior.
I assume the Rust developers figure you'll do enough debugging to root out integer overflow happens, and maybe that's true for the average system, but not all! I once had to write a C++ program to compute Hilbert data for polynomial ideals. The data remained relatively small for every ideal that could reasonably be tested in debug mode, since debug mode is much slower, after all. But once I got into release mode and work with larger ideals, I started to encounter strange errors. It took a while to dig into the code, add certain manual inspections and checks; finally I realized that the C++ compiler was wrapping the overflow on 64 bit integers! which is when I realized why several computer algebra systems have gmp https://gmplib.org/ as a dependency.
OK, that's the problem domain; sucks to be me, right? But I wasted a lot of time realizing what the problem was simply because the language designers decided that speed mattered more than correctness. As far as I'm concerned, Rust is repeating the mistake made by C++; they're just dressing it up in a pretty gown and calling it a princess.
This is only one example. So, sure, Rust is about as fast as C, and a lot safer, but a lot of people will pay for that execution boost with errors, and will not realize the cause until they've lost a lot of time digging into it... all to boast, what? a 1% improvement in execution time?
IMHO the better design choice is to make it extremely hard to override those overflow checks. There's a reason Ada has historically been a dominant language in aerospace and transportation controls; they have lots of safety checks, and it's nigh impossible to remove them from production code. (I've tried.) Nim seems more like Ada than Rust in this respect: to eliminate the overflow check, you have to explicitly select the very-well-named --danger option. If only for that reason, Nim will seem slower than Rust to a lot of people who never move outside the safe zone of benchmarks that are designed to test speed rather than safety.
To be fair, once you remove all these ~1% slowdown checks, you get a much higher performance boost. And Rust really is a huge improvement on C/C++ IMHO, with very serious static analysis and a careful language design that isn't encumbered by an attempt to be backwards compatible with C. So if you're willing to make that tradeoff, it's probably a perfectly reasonable choice. Just be aware of the choice you're making.
This is again confusing perfect bug-freedom and memory safety. Rust does guarantee your code won't have bugs (like integer overflow), but it will never lead to memory vulnerabilities (in safe Rust), which means you'll never encounter a remote code execution caused by and integer overflow in Rust.
The key takeaway is the following: Rust programs will contain bugs, but none of those bugs will lead to the kind of crazy vulnerabilities that allow those “zero-click attacks”. Is that perfect? No, but it's an enormous improvement over the status quo.
Wrapping on integer overflow isn't a memory safety bug in Rust. It's often a memory safety bug in C because of how common pointer arithmetic is in C, and the likelihood that the overflowed integer will be used as part of that pointer arithmetic. But pointer arithmetic is so exceedingly uncommon in Rust that I've never seen it done once in my ten years of using it. This is a place where familiarity with C will mislead you regarding accurate risk assessment of Rust code; wrapping overflow isn't in the top 20 things to worry about when auditing Rust code for safety. And if you want the overflow checks even in release mode, it's trivial to enable it permanently. And a future version of Rust reserves the right to upgrade all arithmetic to panicking even in release mode, if hardware ever sufficiently catches up.
You can enable integer overflow checking in Rust release builds. Android does. I think that trend will continue and at some point even become the default.
