Memory Safety
memorysafety.org
Memory Safety
1–10 of 157 posts
Re: Memory Safety
#2This site is curious in that in incorrectly categorizes go as memory safe.
Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
Re: Memory Safety
#3This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.
Re: Memory Safety
#4[deleted]
Re: Memory Safety
#5This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
By that standard it also incorrectly categorizes rust as memory safe.
Re: Memory Safety
#6This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
I am not sure if you are:
1. attempting to retcon garbage collected languages as not memory safe, or
2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace, it is not an inherent feature of the language, just the implementation, and it is the right practical choice)
But either way: this is the sort of thing I have seen again and again in the Rust "community" that I find deeply off-putting. Build good things, do not play snooty word games.
Re: Memory Safety
#7Now do type safety.
Re: Memory Safety
#8> Languages that are not memory safe include C, C++, and assembly.
False.
C and C++ are not memory safe if you use the most common and most performant implementations, sure.
At some point these folks are going to have to accept that caveat
Re: Memory Safety
#9This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
If we're being extremely strict, Python probably also shouldn't be on that list because the CPython runtime is written in C and has had issues with memory safety in the past.
Ultimately, "memory safety" is a conversation about what a program is intended to do and what semantics the language guarantees that program will have when executed. For the vast majority of programs, you can be just as confident that your Go and Python code will do the right things at runtime as your safe Rust. It's good enough.
Re: Memory Safety
#10This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.
Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.