4 ms·
The problem with unsafe languages is not that you can’t write safe code in them with skill and discipline. The problem is that programmers don’t always do that
by api 1y ago
The problem with unsafe languages is not that you can’t write safe code in them with skill and discipline.
The problem is that programmers don’t always do that, either because they are not that experienced or they are in a hurry.
The real danger is when code is long lived and worked on by multiple people. One bad commit after a late night hacking session and now there is a zero day just waiting to be discovered.
Safe languages don’t rule that out but they make it profoundly less likely.
- bluGill 1y agoI write C++ all the time and I still cannot convince many developers to use unique_ptr over new. It isn't that hard to write code that doesn't leak but if you bypass the language features it cannot help you. for that matter though I've seen rust programmers put everything in unsafe.
- on_the_train 1y agoThere's static analysis which can effectively force these things. C++ problems are self-inflicted
- bluGill 1y agoThere is but we have code predating c++11 that isn't worth rewriting. So the static analisys is off. We do use lots of static analisys but that one is too hard to fix all the old code that we have decades of proff works and isn't leaking (much?)
- andrewflnr 1y agoI mean, a sufficiently safe language would rule it out. Either one not expressive enough to express memory unsafety (i.e. GC or fully linear types with no escape hatches) or one that requires a machine checked proof of safety to compile. These options just happen to be too big of a pain in the assembly for today's appetite.
- api 1y agoThere are lots of languages where true memory bugs are impossible. As you say they are higher level and usually GC.
- andrewflnr 1y agoRight, the interesting case would be the formal proof. Though, I suspect there are fewer high-level languages where memory bugs are actually impossible than you would naively think. I've segfaulted Python by accident, only using the standard library (concurrency shenanigans if I recall). You can probably do worse if you try. To make a truly memory-safe language, you would need to carefully design and implement the standard library, disallow all native code extensions, and probably more I'm not smart enough to figure out. So, not Java, not Python. Maybe some Schemes?