Jonathan Blow

What's Jai's solution to memory safety, then? Something with overhead? "Just don't fuck it up"? Or something else?

Memory bugs are to be avoided, but are a small minority of the number of bugs total. Most bugs are just due to complexity. So “memory safety” is kind of a red herring; if you fix a small number of bugs by gaining memory safety, but in doing so increase friction too much, it is

easily a net loss, because the other 95% of bugs are harder to deal with. Our solution is to provide customizable metaprogramming techniques you can leverage to help with all 100% of bugs, as you feel is best for your own domain and program.

Interesting! As someone who works in a highly logic-bug sensitive field (clinical analysis), I've found that having an advanced type system, incl. memory ownership, is almost always a benefit in reducing logic bugs, as well as memory bugs; have you had a different experience?

Also: a recent post from the maintainer of curl seems to contradict these numbers. Is it possible your experience is not universal here?

I am just talking about the software we ship, though I suspect that if some team's bug load is mostly memory bugs, they are doing something wrong at a basic level. I don't see how memory ownership helps with logic bugs; they are pretty much orthogonal.

First, let's stop speaking in the abstract. Here is the data on curl: https://timmmm.github.io/curl-vulnerabilities-rust/ … and here is Daniel's analysis: https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnerabilities-are-c-mistakes/ … I'm open to the idea that the curl team is doing something fundamentally wrong, but that assertion would require some evidence.