Our great sponsors
-
gmp-wasm
Fork of the GNU Multiple Precision Arithmetic Library (GMP), suitable for compilation into WebAssembly.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
hardened_malloc
Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.
Quoting from https://forum.nim-lang.org/t/8879#58025
> 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.
Quoting from https://forum.nim-lang.org/t/8879#58025
> 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.
Not necessarily; see https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf for example. It's a full chain that repeatedly escalates privileges without exploiting any memory safety bugs by tricking privileged subsystems into giving it more access than it should have, all the way up through and beyond kernel code execution.
I think it's easier to write correct safe Rust than C, I wouldn't say it's easier to write correct Rust with unsafe blocks than C (many operations strip provenance, you can't free a &UnsafeCell created from a Box, you can't mix &mut and const but you might be able to mix Vec and const (https://github.com/rust-lang/unsafe-code-guidelines/issues/2...), self-referential &mut or Pin<&mut> is likely unsound but undetermined), and it's absolutely more difficult to write sound unsafe Rust than C (sound unsafe Rust must make it impossible for callers to induce UB through any possible set of safe operations including interior mutability, logically inconsistent inputs, and panics).
