That would also be a bit confusing because it can be interpreted (incorrectly) as that all languages with garbage collectors offers all the safety guarantees of Rust.
A trivial counterexample is the protection against data races.
Neither that, memory safety, nor forcing you to deal with optionality is unique to Rust.
The big difference is that Rust manages to do these things while also having similar performance characteristics as C/C++. The trade-off is that the programmer has to explicitly deal with these issues.
I personally haven't yet seen a safety language feature of Rust that is not somehow available in other languages with similar claims. I would appreciate learning otherwise if I'm missing something.
I think the only feature that would push Rust to being at the forefront would be "const generics" [1] or true dependent types down the line.
[0] https://en.wikipedia.org/wiki/Software_transactional_memory
Rust is the perfect option for projects that:
1) are exposed to untrusted data
2) and, at the same time, their performance is critical
If one of those isn’t true, there are better options. If they are both true though, Rust is pretty much unique.
Rust and Haskell and standard C and C++ are all non-starters.
The long version is that you could use 'set!' with Vars. But this is very much an avoided practice. Another caveat is that Clojure is hosted (primarily JVM and JS), so any code you call via interop has the characteristics of the host target.
But idiomatic Clojure uses at least Atoms or Refs and even those are discouraged for anything else than storing state, all the algorithmic (transformation, branching and so on) code follows the FP paradigm.
A Rust analogy is the 'unsafe' escape hatch. You can use it but it would be unidiomatic, inconvenient and in most cases unnecessary.
tl;dr: no
Both using 'unsafe' and using String instead of an Enum would compile without runtime guarantees. But such code would stick out.
These markers are irrelevant in a single-threaded scenario.
I’ve googled everywhere but I can’t find a single source of information that completely explains this, possibly showing realistic source code and elaborating the way it could generate memory errors or be miscompiled in case of multiple mutable references.
The TL;DR is: iterator invalidation can happen even without threads.
Another example is if someone tried to use a Vec x inside the closure passed to x.drain.
> doesn’t Rust refuse to compile even when you use non-concurrency safe objects in a single thread?
and given that most types (Vec, HashMap, etc.) aren't "concurrency-safe" (thread-safe?), your answer
> yes
is rather perplexing.
Any language that relies on GC and avoids mutation e.g. by extrmely inefficient data structures (persistent data structures and other immutable data) obviously achieve mostly the same level of safety but at a huge cost.
Unsafe code blocks as opt-in in systems languages appeared for the first time in 1961, followed by multiple variations of it since then, far from being a novelty by now.
One might argue that “well those small parts of a rust program are as unsafe as the entire C# program” but that would be a completely nonsensical argument so I’m going to give you the benefit of the doubt that’s not what you meant.
Besides, the recent security exploits have proven that it is time to go back into multi-processes, and here Rust doesn't have anything to offer.
So one should tune a bit down the tone of labelling all the other languages as unsafe, even managed ones, industry standards like SPARK, or system research languages like ATS.
Do not confuse data races (a subset of race conditions that many languages solve) with race conditions (a way harder problem that there is no general solution to).
> A trivial counterexample is the protection against data races.
Before Rust, I was close to saying that thread-based parallelization was almost impossible to do safely, and was moving to only doing process-level parallelization.