Ask HN: Memory management in go

Following a recent thread on HN about the Zig language [1] and a remark in a video presentation by its author Andrew Kelly to the effect that it's impossible to write perfect software in some other languages including go due to incorrect memory management [2], I was skeptical but did some digging. The go language documentation seems to soft-pedal the whole issue, so the only straight answer I could find short of reading the runtime source code myself was a single post on Stack Overflow, which no one has disputed [3]. I ask this question as a person who really wanted to like go. Since it's impossible to believe that the old school Unix guys who designed the language are naive about this issue, what game is Google playing when it flogs a purported systems programming language in which any code, however carefully written, can crash unpredictably? Do they want the remedy to be unlimited memory, which you can have by signing up for their cloud services? We're told that Google uses go internally. A related question is do they have a hardened version of the runtime that they keep to themselves, or do they rely on an army of devops geniuses and redundant systems to keep it running? (Replies from Googlers are most welcome.) Would it be reasonable to interpret these developments as a part of planned effort to steer programming language design toward a future where reliable software services are feasible only for large organizations to provide? [1] https://news.ycombinator.com/item?id=17057207 [2] https://www.youtube.com/watch?v=Z4oYSByyRak [3] https://stackoverflow.com/questions/30577308/golang-cannot-recover-from-out-of-memory-crash