Well, it is the same 30% that Rust also cannot help much.

In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages.

The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the lang's own semantics.

It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.

Breaking down the full argument is very subtle, sure.

But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language.

To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer.

The whole argument about "saftey" in the sense Rust addresses is between languages of "manual allocation". To imagine that any of these language is "safer", is to have misunderstood a great deal. Rust is about enabling an otherwise C-programmer to limit the impact of manual memory handling, it is *not* to prevent eg,. use-after-free errors in javascript. Since there are no such errors by construction.

The same "by construction" safety applies to Safe Rust as to the dynamic GC'd languages you're discussing. You can't write a use-after-free error in Safe Rust, the same way you can't write one in Javascript.

But, Safe Rust also chooses to construct safety that those GC'd languages don't have.

The reason Javascript doesn't have data races for example is that it doesn't have concurrency - can't have a race with only one runner. Java does have data races (with limited but still unsettling consequences), Go's data races are really bad, like actual Undefined Behaviour bad in some cases. Whereas Safe Rust doesn't have data races - you can write concurrent Safe Rust but you can't write a data race.

The difference you're grappling for probably feels intuitively like it should exist, but I assure you it does not.

You are right that the argument boils down to what we take "by construction" to mean.

I will resolve this, simply, by saying whatever advertisement Rust makes for itself, is better made by any "dynamic" language.

And if we're inclined to trade PR against PR, Rust looses. Managed memory has better PR.

And so those repeating the Rust agitprop against managed languages are simply "NPCs for the wrong ideology".

I would articulate things differently.

Theoretically, memory-safety between Rust and managed languages is equivalent.

However, memory-safe languages (i.e. not Managed C++) running on a memory-safe VM have one more layer of defense in depth than Rust. Additional layers may include, for instance, Unix and containers.

"dynamic" languages, though? That's entirely orthogonal to memory-safety and not very good for general software safety.

Given that F# has unmanaged pointers (nativeptr), wouldn't it also be true that only a subset of it is provably memory safe, just like Rust?