> without a garbage collector, that's the novel part?

That's not quite how it works in various languages. You appear to be thinking of the garbage collector as something inseparable from the language.

Both Dlang and Vlang have optional garbage collectors, that can be turned off. In the case of Vlang, none of its libraries depend on the garbage collector. Vlang offers optional (flexible) memory management, somewhat similar to Nim (but they presently don't have optional ownership).

In the case of Julia and Vlang, their optional ownership is new and experimental. Dlang's optional ownership has been around for some years now, showing that it could be done.

Dlang and Vlang allow you to choose the type of memory management (along with some other languages) that you would like to use. Vlang does it by command line flags. You can turn off garbage collection and turn on ownership.

Yes, it's a critical distinction that's important in many systems domains, but getting some form of ownership policy and method - even if implemented with a GC I think is a step forward in terms of building reliable code.

The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.

True, defaults matter. In many cases, however, using a language that defaults to a GC for memory safety is often preferable or easier.

The argument is often about when ownership and borrowing is truly necessary. Rust has its uses, but arguably not all the time and with everything, because of its defaults.

I’ve marked your words, but I think you have to eat them.

Studies by Microsoft and Google have already been done on this and Rust provides real tangible benefits. No one has ever claimed Rust eliminates all memory errors (if that’s the bar you’re setting), but it makes them vanishingly unlikely, even when you include the prescience of unsafe, thus “eliminating” memory errors (most, not all):

> Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.

The old adage is important: do not left perfect be the enemy of good.

https://security.googleblog.com/2024/09/eliminating-memory-s...

The point of Rust, without counting `unsafe`, is to eliminate memory errors at compile-time. But the point of Rust, when including `unsafe`, is not to entirely eliminate memory errors at compile-time, but to make it feasible to cordon off the unsafe parts into realistically-auditable sections with documented safety invariants. At this it has been dramatically successful, almost beyond anyone's wildest hopes. I have worked on embedded, bare-metal Rust codebases (i.e. the codebases you would most expect to have to do grotty memory faffing) with fewer than 5% of files containing `unsafe` blocks, whereas high-level unsafe code usually has no `unsafe` blocks whatsoever. It's an incredible force multiplier for writing correct low-level code.

Handling of exceptions is not enforced at compile time, while ownership is.

Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.

Rust already has.