A crash is different to a SEGFAULT. Iβd be very surprised to see a safe rust program segfault unless it was actively exploiting a compiler bug.
Sure. I havenβt seen a proper segfault from any modern, post-C/C++ language in ages. Iβve never seen a Go program segfault, or a Nim one (although, there are comparatively few of those as a sample size).
So, it seems to me that - purely from the perspective of a user of programs - Rust still seems about as safe as any other modern language - since Iβve seen no other modern (say, created in the past decade) compiled language segfault. Even the C segfaults seem to be largely becoming rare occurrences, which I have to chalk up to better tooling, because I highly doubt that thereβs been some magical increase in general C programmer quality in the intervening years.
Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isnβt clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.
Go, Java, and Nim (in most cases) are all memory safe but are generally slower than C or C++ due to the ways they achieve memory safety.
Rustβs memory safety approach is zero-cost performance wise, which makes it practical for low level, high throughput, and low latency applications.
Everything is slower than C (I havenβt seen a benchmark yet where a language bests C; even hand-crafted ASM ceded the high ground decades ago when compilers got better than human assembly programmers), but then, C compiler technology has had literally 40+ years to mature.
Go and Java (once warm) do pretty well, but absolutely give up execution speed for coding simplicity and (in Goβs case, anyway) speed. Nim is young; Iβm curious to see how it matures. Theyβre having a bit of a performance crisis at the moment, but assuming they get past that it seems like a fair middle ground between Goβs simplicity and Rustβs bare-metal performance. Then again, manual memory management was absolutely my least favorite thing about C and is what eventually drove me away; worst. Boilerplate. Ever. Even worse than Goβs error handling (which they almost fixed and looks like will be addressed within the next free releases). Anyhoo, going back to that shit is going to be a hard pill to swallow.
Rust is still having its honeymoon, and is the hip language of the decade now. Weβll see!
