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.)
Since we are not at some point in the future where that correct compiler exists and there is only one official compiler, the distinction you make is practically meaningless!
I mean… no? It matters whether something is a part of the language or not, because it matters if you can write code relying on this behavior. Since this is a compiler bug, you cannot - the code will stop compiling the moment the bug is fixed.
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
> 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].
I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
UB is part of the C++ standard. Surely you can understand the difference between the C++ standard and bugs in compilers implementing the C++ standard. This is that.
Rust does not have an ISO standard, but it does have a language design, and if you knew the first thing about cve-rs (including what’s on its own Github page), you would know that this is an extremely confirmed soundness bug.
The cve-rs repo is not meant to be the toxic gotcha aimed at Rust language maintainers you seem to think it is. It’s a repro case.
> I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
Well, you're right about one thing: the fact that I've spent my career in software security doesn't make me "broad consideration". The cites I give on what "memory safe" means, though, do.
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
ISRG is wrong too, definition-wise. Go is not memory safe. It is much safer, and I wouldn’t fault you for taking a C codebase and porting it to Go to avoid memory safety problems, but that does not make it memory safe in the same way Rust et al are memory safe. This is the same way that MTE does not thwart all memory corruption but it stops a lot of them. I accept your premise that Go has brought memory safety over the line to where it is apparently easier to find logic bugs than exploit memory corruption, which is laudable since C(++) has never been able to do this and likely never will, but in line with the pedantry that started this whole chain of comments, it’s not memory safe.
This is not generally considered part of the "memory safety" contract. You can not lift a nil pointer exception into a replacement for Go's "unsafe" library.
When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".
Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'
You can write unsafe code in Go (import unsafe), but then, you can do the same in Rust. Unsafe code is not the default, and in day to day Go i rarely see the use of the unsafe package.
What he probably means is data-races in go can result in memory/type unsafe accesses -- I suspect, likely due to slice types -- not sure if that is true/false.
Sure, but a data race is, IMHO not the same as memory safety. A data race, can be 100% memory safe, but just cause a logic bug in some program. I often see people mixing memory safety with racing. Go has bounds checks so you end up with a panic either way. Not UB.
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
Now you are pushing pixels. A data-race IS a kind of race condition.
My point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
A race condition is an application invariant violation under concurrency, so it has no application-independent definition. A data race is unsynchronized access by two concurrent threads to the same memory location where at least one access is a write. Ergo, the definition of a data race has nothing to do with application logic.
I think this should make the distinction between data races and race conditions pretty clear.
A data race is by definition a class of an race condition. This is basic compsci literature, and there is no other way to put it, as even a non programmer can see the similarity.
Not sure why you would be that nitpicky for something so trivial?
I find this distinction extremely useful in practice because it explains why a static analyzer like Rust's type checker can prevent all data races but can do nothing about race conditions. (Similarly, a dynamic analyzer like ThreadSanitizer can detect data races but not race conditions, because it knows nothing about application logic.)
Meh.. sure a DR is not the same as an RC, but i would class it as a subset of the same thing. You you cant have an RC, you cant have DR, but the other way around.
In the end its the same problem, dressed up differently.
<a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
Russ Cox points out that races are the one place in Go besides unsafe where Go lacks memory safety: <a href="https://research.swtch.com/gorace" rel="nofollow">https://research.swtch.com/gorace
I do think the nitpicking about this is mostly from people that want to say “my favorite language is safer than Go” which stupid and annoying.
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.
nick__m · · focus · HN ↗
simonask · · focus · HN ↗
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
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...
mitxela · · focus · HN ↗
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
simonask · · focus · HN ↗
mitxela · · focus · HN ↗
simonask · · focus · HN ↗
The cve-rs repo is not meant to be the toxic gotcha aimed at Rust language maintainers you seem to think it is. It’s a repro case.
mitxela · · focus · HN ↗
simonask · · focus · HN ↗
aw1621107 · · focus · HN ↗
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
zephen · · focus · HN ↗
saagarjha · · focus · HN ↗
tptacek · · focus · HN ↗
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
saagarjha · · focus · HN ↗
seki285 · · focus · HN ↗
bel8 · · focus · HN ↗
That throws a NullReferenceException
seki285 · · focus · HN ↗
mitxela · · focus · HN ↗
pjmlp · · focus · HN ↗
jerf · · focus · HN ↗
When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".
Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'
[deleted] · · focus · HN ↗
[deleted]
shikck200 · · focus · HN ↗
iambvk · · focus · HN ↗
shikck200 · · focus · HN ↗
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
saagarjha · · focus · HN ↗
shikck200 · · focus · HN ↗
My point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
senderista · · focus · HN ↗
I think this should make the distinction between data races and race conditions pretty clear.
phplovesong · · focus · HN ↗
Not sure why you would be that nitpicky for something so trivial?
senderista · · focus · HN ↗
shikck200 · · focus · HN ↗
In the end its the same problem, dressed up differently.
speedstyle · · focus · HN ↗
<a href="https://go.dev/ref/mem#restrictions:~:text=such%20races,corruption" rel="nofollow">https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...
<a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
tuveson · · focus · HN ↗
I do think the nitpicking about this is mostly from people that want to say “my favorite language is safer than Go” which stupid and annoying.