Is it your expert opinion that Wirth foresaw the problems we have writing this bit-banging code on modern hardware and solved them correctly despite never formalising what they actually are ?
Lists of languages that don't even try to do what Rust is doing here suggest you haven't thought very hard about even what the problem is. Of course if you aren't sure what the problem is it may be trivial to convince yourself that you've "solved" it.
Go has Undefined Behaviour for data races under concurrency. So, while the unsafe package is one obvious way to do dangerous stuff and experience "memory corruption hazards" the rest of the language isn't actually safe.
C# is subject to the whims of the host CLR for both type safety and memory model, and as a result is inherently unsafe on CLRs that actually exist (primarily, Microsoft's) because dangerous was much faster.
They're both dramatically better than C++ and so give us an opportunity to assess Herb's claim that if C++ was 90% safer nobody would bother him about how ludicrously dangerous it is. It does seem like people are comfortable in C# and Go as a result. But, once in a while something very strange happens and it gives these developers no comfort to learn that the Undefined Behaviour was foreseen and they get a WONTFIX back from the language's implementers (e.g. C# can't conceive of how two booleans can both be true yet not equal, however the CLR does not guarantee what C# wants here so C# loses).
So that's what Rust is for. Mostly though, Rust is just very nice to use. I don't actually need Aria's Tower of Weakenings, most of the time I don't need even need unsafe, but I'd still rather be in Rust.
Except those are all examples Rust unsafe isn't designed for, other than by those that misuse its original purpose, even The Rustonomicon advises against it.
As for data races, great that it fixes data races among threads, yet it does nothing against shared resources in distributed computing, which are what really matter in the age of microservices and protection against spectre like attacks.
"In addition, unsafe does not mean the code inside the block is necessarily dangerous or that it will definitely have memory safety problems: the intent is that as the programmer, you’ll ensure the code inside an unsafe block will access memory in a valid way."
Although it appears I stand corrected in regards to Rustonomicon, as it seems to adopt the position that unsafe should apply to more than memory corruption bugs and failed to find the sentence I was looking for.
> Yes, it is pretty good. It was pretty great the last few times you "forgot" about this too.
I never forget about it, from my point of view they are oversold, and will keep arguing they aren't enough for distributed computing deployment scenarios with heavy use of acess to process external shared resources.
Fearless concurrecy isn't something I care about when accessing database rows from multiple threads across database connections, writing to NUMA regions across process and so forth, shared storage,....
Races are still bound to happen in such scenarios, if care is not taken, and fearless concurrency is of little help in such cases.
