Earlier quoted context omitted.
> For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a long time with a difficult decision, which trade-offs to make. Indeed, in 2009 Russ Cox laid out clearly the problem they had [1], summed up thus: > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow executio…
Ironically, the latest research by Google has now conclusively shown that Rust programmers aren't really any "slower" or less productive than Go programmers. That's especially true once you account for the entire software lifecycle, including production support and maintenance.
In this context, the the "slow programmer" option was the "no generics" option (i.e., C, and Go before 1.18) -- that is, the programmer has to re-implement code for each separate type, rather than being able to implement generic code once. Rust, as I understand it, followed C++'s path and chose the "slow compile time and bloated binaries" option (in order to achieve an optimized final binary). They call it "zero cost abstractions", but it's really moving the cost from runtime to compile time. (Which, as TFA says, is a tradeoff.)