This one bug greatly undermined my confidence in Go forever: <a href="https://github.com/golang/go/issues/64474">https://github.com/golang/go/issues/64474</a><p>That this can happen in the standard library and stay in a stable release for 5-6 months, in fact very nearly making it to Go 1.22, means that Go's quality assurance pipeline is not adequate for use in production. (The actual bug is in the runtime, but that's irrelevant; it's a runtime optimization for an API offered in the standard library)<p>It also reopens a larger question, that if the Go teams seriously believes it is okay for a modern programming language to offer no ways whatsoever to enforce immutability or exclusive ownership, leaving programmers to reason about such things themselves throughout every project, then they have to hold themselves to a higher standard to prove that this is reasonable to expect.<p>Similarly, it is also really concerning that they don't consider this a CVE when it obviously could be; a user receiving a shallow cloned map could modify data affecting other users.<p>That the Go team does not consider this a headline item, let alone a CVE, let alone something that should change how Go is developed and qualified, is all I need to know about how little they care about production grade software. People choosing to use Go in production should at least know what they're getting themselves into.