This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
> Isn't ten years enough to call something a feature of the language rather than a bug?
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
u8 · · focus · HN ↗
OutOfHere · · focus · HN ↗
typical182 · · focus · HN ↗
See for example comments from tptacek like:
<a href="https://news.ycombinator.com/item?id=43335748">https://news.ycombinator.com/item?id=43335748
<a href="https://news.ycombinator.com/item?id=46028232">https://news.ycombinator.com/item?id=46028232
<a href="https://news.ycombinator.com/item?id=44672371">https://news.ycombinator.com/item?id=44672371
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
mitxela · · focus · HN ↗
simonask · · focus · HN ↗
At some point in the future, a fully backwards compatible Rust compiler will report an error when you try to compile cve-rs.
ghusbands · · focus · HN ↗
I like Rust, but with this bug existing for so long, I personally no longer think of it as memory-safe.
aw1621107 · · focus · HN ↗
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
[0]: <a href="https://news.ycombinator.com/item?id=40431444">https://news.ycombinator.com/item?id=40431444
[1]: <a href="https://blog.rust-lang.org/2026/08/21/enabling-next-solver-on-nightly/" rel="nofollow">https://blog.rust-lang.org/2026/08/21/enabling-next-solver-o...