Jonathan Blow

There is value in having more confidence that your program is memory-safe, if you are concerned about attackers. (But I also think we should just redesign our operating systems so we are less worried about attackers).

I think you're underestimating the influence of memory safety. In particular, more than avoiding vulnerabilities, it's avoiding aliasing: every bit has a clear owner. The compiler forces you to do that. And that is incredibly helpful. Lemme try to explain what I meanx

Think of a multithreaded system. How do you cooperate between threads? How do you share memory? That is not easy, and more often than not you end up pulling the rug from under some other thread's feet.

Rust forces you to not do that: only one thread can examine memory that's being modified at one particular time. This is their restriction on aliasing.

But how is this useful outside of a multithreaded scope? Well... Think of a library that you're building. Maybe a simulation, given your background on videogames. The more distant two pieces of code are, the least conscious you are of the influence one has over the other.

This is just like how two threads are very difficult to understand together. Will you modify _this struct_ somewhere in the simulation, far from this section of code? Who knows. Well, by limiting aliasing you can actually prove that you won't. That's one way Rust prevents bugs :)

This would be fine if the kind of problem you are describing was responsible for a significant percentage of our bug load. But it isn't.

In general this kind of rhetoric you are giving me, I feel, is driven by theoretical ideas, rather than a data-driven approach to how do we minimize software bugs. Which is fine, but then I wish Rust people would admit that, rather than claiming they are addressing correctness.