5 ms·
> Node.js and Go are considered practically safe language Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/ https://w
by cetra3 10mo ago
> Node.js and Go are considered practically safe language
Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/ https://www.cvedetails.com/cve/CVE-2021-22940/
Go is also not Memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html https://www.ralfj.de/blog/2025/07/24/memory-safety.html
- tptacek 10mo agoNode.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++.
- GaggiX 10mo agoIt'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 10mo ago"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 10mo agoThe 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 10mo agoIt's got really not much at all to do with `unsafe`.
- benjiro 10mo ago[flagged]
- tptacek 10mo agoI didn't downvote you and couldn't have (you were replying to me). Please don't comment about the voting on comments. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- benjiro 10mo ago[flagged]
- vacuity 10mo agoWhile unsafe is always a risk in Rust, measuring the risk is not nearly as straightforward as counting lines of code. In particular, Rust focuses on encapsulating unsafe code behind safe wrappers that prevent misuse, so the better measure is determining which crates don't do this, and to what extent they can be easily patched to do so.
- mirashii 10mo agoI 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 10mo agoThe 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.
- rowanG077 10mo agoHaving 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.