I found this interesting (regarding Go): "we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason".
As a fan of minimalism over complexity, I like the idea, but I can't help but wonder if three of the world's best programmers are the best qualified to decide what programmers in general need. For example, if you can dash off a correct, performant, and theoretically sound version of a data structure in a couple dozen lines of code and 15 minutes, I bet generics seem much less useful.
However, I do prefer that to designing to the lowest common denominator.
The older I am the more I come to the conclusion that best programmers aren't those who can bang out complex code, but those who can find a reasonably simple way to implement even complex concepts. This does not work all the time, but mostly when I start to write "heroic" code I simply back up and try to find what I am doing wrong. Maybe this is the case with the authors of Go.
Keeping things simple is hard. It takes a willingness to admit your mistakes and the time to go back and correct them.
If you want something to last, you've got to fight to keep it from rotting under the weight of its own design. The less design, the more easily it can adapt to change.
Ingrained in the Go project is the philosophy that things are always worth fixing, no matter how small. I don't think the value of this idea can be overstated.
As a fan of minimalism over complexity, I like the idea, but I can't help but wonder if three of the world's best programmers are the best qualified to decide what programmers in general need. For example, if you can dash off a correct, performant, and theoretically sound version of a data structure in a couple dozen lines of code and 15 minutes, I bet generics seem much less useful.
However, I do prefer that to designing to the lowest common denominator.