Hacker News Reader

While that keeps being given as example, Go is not C, C++, Objective-C levels of memory corruption opportunities.

Lets not let the perfect be the enemy from good.

Even with all my criticism of many Go's design decisions, I rather have more infrastructure code being written in Go than C, and derived languages.

Or any of the supposed better C alternatives, with manual memory management and use after free.

Go maps don't have enough locking to be thread safe, as I understand it. That was true at one time. Was it fixed?

I would not expect that it makes sense to provide this as the default for Go's hash table type, my understanding is that modern Go has at least a best effort "fail immediately" detector for this particular case, so when you've screwed this up your code will exit, reporting the bug, in production and I guess you can curse "stupid" Go for not allowing you to write nonsense if you like, or you could use the right tool for the job.

Isn't it strange that they created a new language where one of its main selling points is concurrency, and punted on that design issue.

(Yes I'm aware that Go literature 'encourages' the use of Channels and certain patterns)