They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them.
Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.
And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types.
Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap).
Does that mean writing a separate version of an algorithm for each type or types that you want it to handle? Like a sort for ints, a sort for floats, etc., even if the logic is otherwise the same (or almost)?
Not a PL design or theory expert, just interested.
There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.
Hybrid approaches in which the compiler (or JIT!) decides whether to monomorphize or use vtables are also possible.
Also the Swift optimizer can clone and specialize generic functions within a module, eliminating the overhead of indirection through reified metadata.
The compiler specializing/monomorphizing as an optimisation shows that Swift has a hybrid approach that tries to balance the trade-offs of both (like many other languages, like Haskell, and, with explicit programmer direction, Rust), but the two schemes still fall into the broad categories of monomorphizing vs dictionary passing, not something fundamentally different.
Yeah as pointed out in that very thread by pjmlp:
As usual, it lacks discussion about generics in:
> They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them.
Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature.
> there's definitely a lot of research in that area.
That there is, would be nice if Go's designers ever bothered actually using it.