> We all know Go doesn't have generics - that topic has been beaten to death, so let's not derail the discussion and just say this can be a valid reason for Go not fitting your use-case.
Parents point was that Go will still box primitives in a generic collection class...just like Java does. So this isn't a special advantage of Go at all (it has nothing to do with Go not having type parameters). The only languages that don't box in generic collections is C++ and perhaps C# (it doesn't have to because of its template-like type parameter semantics, but still might to reduce code duplication).
Right. Although the template method has its own issues. For example, once the element type size exceeds 64 bits, you can no longer assume an atomic write/read. This isn't a big problem considering that concurrent data structures don't usually rely on the write/read atomicity of the elements themselves (though they do rely on atomicity of modifying internal, structural data), but that's just something to think about.
Parents point was that Go will still box primitives in a generic collection class...just like Java does. So this isn't a special advantage of Go at all (it has nothing to do with Go not having type parameters). The only languages that don't box in generic collections is C++ and perhaps C# (it doesn't have to because of its template-like type parameter semantics, but still might to reduce code duplication).