That's not the claim. The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim.
Go's lack of generics is a design tradeoff. The occasional piece of awkward code is worth the overall reduction of complexity at an environmental level.
The Go creators do not deny that generics would make things easier. In particular, concurrency is one area where some kind of parametric type system would be really helpful. But we, and many others, are finding Go to be a great tool for a wide variety of jobs. It has won developer mindshare specifically because of our focus on simplicity. It doesn't seem worth compromising that to reduce the occasional bit of repetitive code.
I strongly dispute/oppose that claim.
1) Generics don't add any complexity to the rest of the language. If you don'y use generics, you're back to the "plain Go". Especially since generics doesn't mean just "ML-style polymorphism"; I'm pretty sure that many people would be happy with a very limited implementation of generics, e.g. only for reference/pointer types (or even only for interfaces), with all types/generic arguments declared, not inferred. In that case, implementing generics would only require a change of the type-checker of the language, or in the case of Go, not even that, which brings me to the second point:
2) Generics are already implemented in Go (the compiler/the language/the libraries), via map/arrays/slices, it's just not accessible to user code. I really can't see how anybody could make an honest claim that "Go is avoiding generics because of added compiler complexity", when that complexity is already there.
The issue is that a programmer needs to understand how the generics model works and how it interacts with every other feature of the language. That makes the language more complicated, which (as you say) leaks into the higher levels.
Generics is just one of many features that Go could have, but does not because it makes the language bigger.
Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.
But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.
> Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.
> But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.
And here's where we begin to disagree.
I delete redundant comments in code, even if they're correct.
This is significantly more effort than leaving them alone: I have to recognize they're redundant, check VCS history to ensure I'm not missing something, create a changelist, request a code review for the changelist, wait for the reviewer to verify I indeed didn't missing something, submit the changelist, verify the changelist still builds (you never know when you'll hit a bizarre compiler bug, corrupted file, conflict resolution related typo), merge the changelist back to the mainline...
This is a significant amount of work! But I feel it's justified: they're increasing the complexity involved with reading the code. The more pointless redundant comments I'm reading, the less important things I can remember, and the more likely I am to skim over something important such as a bug.
This is not additional cyclomatic complexity in the codebase. Structurally, the complexity of the fundamental operations my program performs haven't changed - I haven't touched anything that should affect the final executable output in any meaningful form at all. But I'm still making it simpler* to read.
(* a synonym of simple to note: noncomplex!)
In non-comment code, the problem is much worse. More code means more opportunities for typos, more code which must be read to grok the actual execution of the code. If you thought bugs got missed when I was skimming past the comments, well let me tell you, it's way worse when I start skimming past the code! And this happens to everyone.
There are still a few people who don't mind writing all their programs in straight up assembly. Sure, it's a bit more code, but all the if and while conditionals from C aren't reducing the cyclomatic complexity of their programs either compared to structured programming with conditional jumps. They say there's more important things to worry about than pure line count - and they're entirely correct. They're writing codebases in assembly that I'd find much more readable than some of the codebases I've read in much much higher level languages.
But having addressed the more important stuff I'd still like to address the less important stuff. It eventually adds up, and I've seen it make me more productive. (This has encouraged me to try many different languages... so far not Go, I've yet to come up with a problem which makes it the right language for the job.)
(Note that I am in disagreement - I do think generics should be added).
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."
"It is possible to compile a large Go program in a few seconds on a single computer."
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.
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.
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?
There is also a chance that it will slow down compilation and or runtime. Java, C++ and other code compiles slower. Is it because those languages are stupid and slow and made by idiots? Not necessarily, it is because they have more features. Many added later (with added complexity of keeping backwards compatibility). The fear I think, is if Go gains those new features, its compilation and/or execution speed or claims of simplicity will not hold any more.
Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see generics.
Yes, any new language feature may slow down the compilers and/or runtime. Go values compilation and execution speed highly very highly. To include any new language feature we would assess whether it is worth the various costs; that much is obvious.
But there are technical reasons why C++ and Java could never compile as fast as Go, and they have nothing to do with generics. Go's dependency model is the main reason it can build fast.
And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.
Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more.
> We didn't build Go in order to have arguments on a mailing list.
Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.
In practice it's pretty much a measure of the temperature of bear porridge that a given person currently finds just right.
Eiffel, Ada, D, Modula-3, Active Oberon, FreePascal, Delphi... enjoy fast native code compilers and do have generics.