They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere.
(Note that I am in disagreement - I do think generics should be added).
(Note that I am in disagreement - I do think generics should be added).
"It is possible to compile a large Go program in a few seconds on a single computer."
[1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project
you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.
It is a good sell when the audience only knows about C++ compilation issues.
What kills compilation performance for larger C/C++ projects is include hell and managing build dependencies, which as you point out is mitigated in language with modules.
Not sure. If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.
It looks like the go compiler in itself is a nice piece of engineering, like a F1 race car. And a bunch of guys say they want it with automatic gears. Proposing an automatic version would change too many things in the internals, and the result would be another kind of cars.
Why would that be the case for Generics?
I think nobody says "Go needs Generics, but the implementation needs to be horrible."
People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
Well, I guess I'll keep not being a Go programmer :)
That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?