‘Zero-click’ hacks are growing in popularity

https://medium.com/@tinocaer/how-microsoft-is-adopting-rust-...

https://preettheman.medium.com/this-is-what-apple-uses-rust-...

99% of the time if you're fighting the borrow checker and just want a quick solution, that solution is `clone` or `Arc>`, not `unsafe`. Those solutions will sacrifice performance, but not safety.

> 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.