But, while I know nothing is a panacea, memory safety is especially not a panacea. We have over a decade worth of experience with software built principally in memory-safe languages; it's hard to find a modern web application --- increasingly, it's even hard to find a modern mobile application --- built in a language as bad as C. And, as you know, all these memory-safe applications are riddled with vulnerabilities. They don't have memory corruption vulnerabilities, but I'm still game-over'ing app pentests, and very unhappy with myself when I can't.

And even wrt memory, Rust (with the standard library) is not free of its own warts, see the OOM situation. See e.g https://news.ycombinator.com/item?id=10545877 for a discussion on this.

Just to be clear: I generally like the ideas of Rust. I just dislike its presentation by some as a magic solution to all kinds of concerns.

Anyway, you suggested Rust under false assumptions. Rust doesn't care about reliability and security any more, than most of the modern languages. Even Perl with its taint mode is more secure, than Rust.

Lots of people confusing "memory safety" with the high degree of thread safety offered by Rust. Memory safety is in everything modern except C and C++, and ASM. It's the present baseline, except those.

Nobody is proposing new memory unsafe languages.

Only a few straggler developers, possibly with the same confusion, are loudly insisting they somehow need memory unsafe languages. When you consider what "memory unsafety" means, the claims are transparently risible. Nobody needs the ability to access arrays out of bounds. Nobody needs access to unallocated memory. It's not a serious desire, it's just contrarianism or confusion about what it is.

My question is: Who offered memory safety on its own, historically? I think the reason that memory safety has been a tough sell historically is that it always came with performance overhead and lack of low-level control, and people kept using C and C++ for low-level programming as a result. By contrast, Rust tries to go farther than any other industry language in truly providing memory safety on its own—without any of the baggage of JITs, or garbage collection/pervasive reference counting. If you had to sum up the raison d'être for Rust in one sentence, that'd be it.

I think that historically, memory safety "on its own" hasn't been tried, at least to the degree that Rust strives for.

Why C++ will probably not be changed by other languages is the freedom it provides. It is a language equivalent of giving you absolute power of everything, including digging a massive hole, falling into it and not being able to crawl back out.

Yes, Rust is safer in and of itself, and "encourages" safety, but it is also like riding a bike with a safety wheels and cushions strapped everywhere. At some point it will start just getting in your way more than helping you.

In the end it boils down to purity and elegance vs. efficiency and practicality. And I'm bigger fan of efficiency and practicality than purity and elegance.

Centralizing the memory management code to some well tested core---like the Rust compiler or some C lib---sounds to be the crux of wiring memory safe code, not the language.

> even Rust programs don't give you sound guarantees for memory safety as many of them depend on unsafe code that isn't soundly proven

There's no such thing as 100% memory safety; at the extreme end there are bit flips caused by cosmic rays. But the evidence suggests that practical language-enforced memory safety is actually worthwhile, despite the fact that no theoretical absolute memory safety is possible. All memory-safe languages have runtimes and FFIs, which in Rust is the unsafe blocks. This doesn't change the fact that, empirically, memory safety, even the imperfect memory safety we have to live with in the real world, is a meaningful improvement in stability and security.

> That the cheapest way to write such programs is to have sound guarantees for everything is an interesting hypothesis, which would get you a language like, say, Idris, but it is not the consensus.

Straw man. Nobody is talking about proving all code correct. What is reasonably describable as consensus nowadays is that having the language enforce memory safety is worthwhile. The idea that enforced memory safety has, in your words, "more downsides than upsides", is increasingly at odds with the consensus.

To get concrete, I see no reason to believe that quarantine (Zig's current solution to UAF) is a meaningful solution to use-after-free problems, given that quarantine has been deployed for a long time in production allocators in other languages and has failed to eliminate this bug class in the wild.

As a former C++ developer, errors leading to crashes (be it due to memory or otherwise) were always more preferable to me than logic errors or race conditions (which can still happen in Rust) that go unnoticed for months/years. I guess 'danger' here is subjective, but thats my view.

Billions and billions of dollars. Large organizations like Microsoft and Google have published numbers on the proportion of vulns in their software that are caused by memory errors. As you can imagine, a lot of effort is spent within these institutions to try to mitigate this risk (world class fuzzing, static analysis, and pentesting) yet vulns continue to persist.

Rust is not the solution. Memory-safe languages are. It is just that there aren't many such languages that can compete with C++ when it comes to speed (Rust and Swift are the big ones) so Rust gets mentioned a lot to preempt the "but I gotta go fast" concerns.

I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server.

Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash.

Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash.

In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug.

This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language.

(I know this is ironic coming from me, who designs a memory-safe language full-time!)

My comment was about the tradeoffs we make for our memory safety guarantees.

But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections.

Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.

I wonder if memory safety had mattered more, whether other languages might have caught on a bit more, developed more etc. Rust is the new kid, but memory safety in a language is not a totally new concept.

The iphone has gone down the memory unsafe path including for high sensitivity services like messaging (2007+). They have enough $ to re-write some of that if they had cared to, but they haven't.

Weren't older language like Ada or Erlang memory safe way back?

A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this.

We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side.

Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.