Comment by lmm
2 days ago
> research on other safe alternatives is slow
It's slow because the potential benefits are slim and the costs of doing that research are high. The simple reality is that there just isn't enough funding going into that research to make it happen faster.
> there's no compelling reason that rust has to be the only way to achieve memory safety
The compelling reason is that it's the only way that has worked, that has reached a critical mass of talent and tooling availability that makes it suitable for use in Linux. There is no good Rust alternative waiting in the wings, not even in the kind of early-hype state where Rust was 15 years ago (Zig's safety properties are too weak), and we shouldn't let an imaginary better future stop us from making improvements in the present.
> it might do to wait until some other memory safe alternative appears.
That would mean waiting at least 10 years, and how many avoidable CVEs would you be subjecting every Linux user to in the meantime?
> The compelling reason is that it's the only way that has worked
because it's hard enough that people don't try. and then they settle for rust. this is what i mean by "rust sucks the air out of the room".
however, its clearly not impossible, for example this authors incomplete example:
https://github.com/ityonemo/clr
> That would mean waiting at least 10 years,
what if it's not ten years, what if it could be six months? is or worth paying all the other downstream costs of rust?
youre risking getting trapped in a local minimum.
> because it's hard enough that people don't try. and then they settle for rust. this is what i mean by "rust sucks the air out of the room".
I think it's the opposite. Rust made memory safety without garbage collection happen (without an unusably long list of caveats like Ada or D) and showed that it was possible, there's far more interest in it now post-Rust (e.g. Linear Haskell, Zig's very existence, the C++ efforts with safety profiles etc.) than pre-Rust. In a world without Rust I don't think we'd be seeing more and better memory-safe non-GC languages, we'd just see that area not being worked on at all.
> however, its clearly not impossible, for example this authors incomplete example:
Incomplete examples are exactly what I'd expect to see if it was impossible. That kind of bolt-on checker is exactly the sort of thing people have tried for decades to make work for C, that has consistently failed. And even if that project was "complete", the hard part isn't the language spec, it's getting a critical mass of programmers and tooling.
> what if it's not ten years, what if it could be six months?
If the better post-Rust project hasn't appeared in the past 15 years, why should we believe it will suddenly appear in the next six months? And given that it's taken Rust ~15 years to go from being a promising project to being adopted in the kernel, even if there was a project now that was as promising as the Rust of 15 years ago, why should we think the kernel would be willing to adopt it so much more quickly?
And even if that did happen, how big is the potential benefit? I think most fans of Rust or Zig or any other language in this space would agree that the difference between C and any of them is much bigger than the difference between these languages.
> youre risking getting trapped in a local minimum.
It's a risk, sure. I think it's much smaller than the risk of staying with C forever because you were waiting for some vaporware better language to come along.
Even if you are releasing such a solution today, it will take months/years to build knowledge and toolchains and best practices. Then have traind developers to be able to use it.
> youre risking getting trapped in a local minimum.
Or you are risking years of searching for perfect when you already have good enough.