18 ms·
The problem with go here is (a) garbage collection, such that rust likely wouldn't have needed any unsafe outside of well-known libraries; and worse (b) when yo
by unanswered 6y ago
The problem with go here is (a) garbage collection, such that rust likely wouldn't have needed any unsafe outside of well-known libraries; and worse (b) when you need to do stupid C shit in go, there's no `unsafe` to contain it; it just spews over the rest of your code.
"Principled policy and software design" is exactly what's needed to get rid of memory bugs in C too! So we can conclude that these things are impossible, or else we would not need memory safe languages in the first place. Since it's increasingly apparent that go requires these mythical safeguards after all, it's safe to say that it is not a memory safe language in the useful sense.
- reikonomusha 6y agoIn general, I think this all-or-nothing attitude paired with FUD language is detrimental to good engineering. Memory unsafety is generally bad, I get it. But it’s exaggerating to say that these things “spew” all over codebases, or that you’re entering some inescapable memory hell that has no way to be treated properly. The original proposal was to manage some memory yourself within Go to solve one very specific problem with a very specific module of code. That’s not a lot of surface area and has a clear API. It doesn’t seem unfathomable that qualified, highly paid engineers can’t do a good job solving that problem comprehensively without rewriting everything else.