This article fails to mention that the true semantics of Rust's `unsafe` subset has been very much up-in-the-air for a long time. Nowadays the `miri` interpreter is supposed to be giving us a workable model for what `unsafe` code is or is not going to trigger UB but many things are still uncertain, sometimes intentionally so as some properties may depend on idiosyncratic workings of the underlying OS, platform and/or hardware. These factors all make it harder to turn what's currently `unsafe` into future features of safe Rust, perhaps guarded by some sort of formalized proof-carrying code.
I could be wrong, but my impression from posts like this one https://www.ralfj.de/blog/2020/12/14/provenance.html is that even C doesn't have a fully coherent model for what happens when we start doing weird things with pointers. Apparently there are LLVM bugs open that ultimately need to be addressed by the standards committee?
Progress towards this is always being made, though it's a long road with much still to determine. I encourage anyone interested in this to join the Zulip channel for Rust's unsafe code guidelines working group: https://rust-lang.zulipchat.com/#narrow/stream/t-lang.2Fwg-u...
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.
