Comment by androidcode
6 months ago
Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
This is not a theoretical exercise. https://materialize.com/blog/rust-concurrency-bug-unbounded-... .
AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.
And even for memory-unsafe languages like Rust, there are trade-offs.
> Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust.
What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?
> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.