| Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust. There are essentially just two mainstream memory-unsafe languages: C and C++. |
| |
| ▲ | rowanG077 3 hours ago | parent | next [-] | | Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go. | |
| ▲ | GaggiX 3 hours ago | parent | prev [-] | | It's easy to cause memory corruption with Go while building a concurrent system, you don't need to learn anything about "defeating the language". | | |
| ▲ | tptacek 3 hours ago | parent | next [-] | | "Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no). An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits. | | |
| ▲ | benjiro 3 hours ago | parent [-] | | The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword. The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind. Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it. Rust code with unsafe: 1.7M
Go code with unsafe: 400k and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword. | | |
| ▲ | tptacek an hour ago | parent [-] | | It's got really not much at all to do with `unsafe`. | | |
| ▲ | benjiro an hour ago | parent [-] | | Author mentions this and love the downvote. Typical in any topic with Rust. | | |
|
|
| |
| ▲ | mirashii 3 hours ago | parent | prev [-] | | I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived. My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on. | | |
| ▲ | tptacek an hour ago | parent [-] | | The same thing happens any time a message board confronts a professional term of art. The same thing happened with "zero trust", where you'd have long wooly debates about what was meant by "trust", but really the term just meant not having a conventional perimeter network architecture. Sorry, but the term as used in industry, by the ISRG, and in government guidance refers specifically to vulnerabilities. |
|
|
|
