This claim is a bit too broad based on my limited understanding. Please correct me if I'm wrong:
First, Rust is not actually a memory safe language. It makes writing memory safe code easy and nudges you towards writing "unsafe" code in specific places. This is a good thing and many get away with not requiring programmer asserted safety. But it's also important to note that ultimately it relies on it.
Second, The borrow checker seems to primarily check that you're doing RAII properly. In a sense it answers the question of:
"What if we get the predictable nature of stack allocated memory for the heap?"
Clever, but that leads to a proliferation of lifetime annotations (which are part of your types) and makes code very brittle and rigid if spelled out as is. Because every lifetime that is encoded that way, has to fully cover the scope that encloses all of its usage. And if that weren't enough, it also infects almost every data structure that is some way composed of references.
There seems to be multiple ways of dealing with this issue that I've come across when learning the language:
1. Avoiding pointer references whenever possible and using self-managed vector/slice/hashmap references.
2. Introducing GC via reference counting.
3. Cloning.
4. Macro or trait abstraction.
When we're doing 1, we don't gain much utility from the borrow checker.
When doing 2/3 we would be better served if we used a language with a battle hardened and optimized GC runtime.
I've seen 4 in some cases, but never looked like it's "bringing safety to the masses". The whole API around traits and macros is very rich, very sophisticated and very subtle.
I would rather phrase it as: "Rust brings ML/functional concepts to C++ programmers and it explores a new space of compiler optimizations based on that."
However the Rust _community_ does bring these concepts to the masses. They have written excellent books and recorded multi hour long videos explaining and exploring the language and making this all accessible.
By the standard of your “first,” no language is a memory safe language. They all must rely on unsafety in the implementation of their runtimes in the same sense that Rust builds safe abstractions on top of unsafe code, and many even offer FFI, which is conceptually similar to calling an unsafe function.
Most memory safe languages lack enough power to implement their own runtime systems (except in an extremely inefficient way), because so many languages ultimately rely on an implementation in another unsafe language that has access to machine capabilities. Implementing the runtime system in the language itself is a black art that requires an unsafe dialect or extension. E.g. all the Java-in-Java VMs sneak dialect features in through intrinsic classes like "Pointer" and such that are recognized by their own extended compilers.
First, Rust is not actually a memory safe language. It makes writing memory safe code easy and nudges you towards writing "unsafe" code in specific places. This is a good thing and many get away with not requiring programmer asserted safety. But it's also important to note that ultimately it relies on it.
Second, The borrow checker seems to primarily check that you're doing RAII properly. In a sense it answers the question of:
"What if we get the predictable nature of stack allocated memory for the heap?"
Clever, but that leads to a proliferation of lifetime annotations (which are part of your types) and makes code very brittle and rigid if spelled out as is. Because every lifetime that is encoded that way, has to fully cover the scope that encloses all of its usage. And if that weren't enough, it also infects almost every data structure that is some way composed of references.
There seems to be multiple ways of dealing with this issue that I've come across when learning the language:
1. Avoiding pointer references whenever possible and using self-managed vector/slice/hashmap references.
2. Introducing GC via reference counting.
3. Cloning.
4. Macro or trait abstraction.
When we're doing 1, we don't gain much utility from the borrow checker.
When doing 2/3 we would be better served if we used a language with a battle hardened and optimized GC runtime.
I've seen 4 in some cases, but never looked like it's "bringing safety to the masses". The whole API around traits and macros is very rich, very sophisticated and very subtle.
I would rather phrase it as: "Rust brings ML/functional concepts to C++ programmers and it explores a new space of compiler optimizations based on that."
However the Rust _community_ does bring these concepts to the masses. They have written excellent books and recorded multi hour long videos explaining and exploring the language and making this all accessible.