[excepttheweasel]

> In many cases, that up-front cost is paid back many fold later, when other programmers (or you yourself, after you’ve forgotten the details of the code) come and try to read and work with the code. Go optimizes more for understanding the code later than for building big things quickly.

I believe this sounds attractive in part because programmers are so excited by the idea of solving problems, and it's true that a specialized implementation can always beat a general one. But it does not sound particularly sustainable.

A language that doesn't provide adequate abstractions often results in requiring its users to develop those missing abstractions over and over again. With the requisite possibility of bugs or implementation naivety. As both a Rust and Go user, I do find the talk of generics a little over played. Go has great facilities for code reuse that often mean you won't miss generics as much as you might think. But I also see Go projects growing in size quicker than I can appreciate. The increased volume of code, each piece being specialized for its particular purpose - harder to fit in my head at one time. The cost of changing the code becomes more severe, each instance of an abstraction in the code being different enough to warrant specialized attention, rather than fixing code in a single place.

In every organization I've worked at, as the size of a code base grows, so does the cost of change. A language that doesn't scale well is only going to exacerbate that problem. Perhaps Go seems great now because we've yet to really see any projects written in it at this scale.