Exactly, when we talk about RiiR, we are saying, "I would like to have the guarantees that Rust provides". If the Rust ecosystem depends heavily on C/C++ libraries, then the system has the properties of the union of all the flaws and the properties of the language do not translate into a quality of the ecosystem.

That said, I think containing C/C++ to a Wasm sandbox that can be integrated transparently with Rust would be a gigantic win for security, correctness and the Rust ecosystem.

>"I would like to have the guarantees that Rust provides". If the Rust ecosystem depends heavily on C/C++ libraries, then the system has the properties of the union of all the flaws and the properties of the language do not translate into a quality of the ecosystem.

Of course ideally you get rid of all C/C++, but that may not be feasible. Combining Rust with some C/C++ still adds the benefit of Rust safety to the new code you write. The contained C/C++ is like the unsafe section of Rust code, a place where you have to be more vigilant, but you're slowly constraining the space where these issues can arise. And you can iteratively only replace those parts that cause a lot of issues.

TBH I still don't see it happening or being the case atleast in the near foreseeable future...

Why you may ask..? The answer is simple cause there is always a cost. So the question is what is easier or when can one say the cost of using a "safer" language out weighs a "less safer" one..

Cause otherwise Rust is also too damn unsafe, just move to something completely safe Idris could be a good starting point. /s

Putting the sarcasm aside. Rust is does not guarantee Memory safety, it tries to help with it. (Check Reference Cycles) The safest feature of Rust would be it's protection against Data Races.

So at the end it's all about the trade-offs and deciding what you are willing to sacrifice and what you aren't...

Over the medium term (years to decades), there is no question that rewriting in a safe language is worth the cost. It's a one-time project, and security issues cost our economy billions on an ongoing basis.

Rust isn't perfect, and perfect automatically-checked safety probably isn't possible, but it's dramatically safer than C/C++, and cuts down the amount that would need to manually audited to the point where it would be feasible to do it comprehensively.

I agree that everything should be made in a memory safe-by-default language like Rust and I really need to see the Rust ecosystem really commit to this. Too many times will I come across a library with some very questionable uses of `unsafe`, which in my opinion has no place in things like HTTP request libraries or web frameworks.

Yep, on my domain it has been Java and .NET.

When was the last time a Java or .NET codebase had an RCE from writing past the end of a list? The only RCEs in safe languages generally only happen in uncommon explicit code-loading calls or explicitly unsafe memory access calls.

More than Rust in multithreaded scenarios, actually.

Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic<> on CUDA.

While you keep being baffled, where is Rust's memory model specification?

There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET.

Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be unsafe, but still allow arbitrary unsynchronized operations. These will likely end up with an incorrect result, even if there's no memory unsafety, and may completely violate any internal invariants of the object or data structure. This latter point means one cannot write a correct abstraction that relies on its invariants without explicitly considering threadsafety (it is opt-in safety), whereas Rust has this by default (opt-out safety).

Rust has essentially adopted the C/C++11 concurrency model.

Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent.

Not saying that it isn't important though.

Ownership/affine typing does allow modelling that, within a single program.

For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").

Assuming you are accessing the distributed resource from multiple threads instead of multiple distributed processes, which is quite common in distributed architectures.

Borrow checker doesn't help at all with process IPC.

Plus all ML derived languages have good enough type systems to model network states, while enjoying the productivity of automatic memory management.