>, but the fact is that some people in enjoy the simplicity that comes from Go not having them.
The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.)
As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process.
Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash.
However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.
> The Golang team was not extolling the lack of generics in Go as a point of pride.
Indeed, they're extolling the simplicity one gets. To quote their FAQ:
> Why does Go not have generic types?
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better.
> As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion.
That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
>Indeed, they're extolling the _simplicity_ one gets. To quote their FAQ: [...]
If they can find a way to add it that doesn't take away the _simplicity_
You're missing my point because you've used "simplicity" twice in a way that I was trying to define in a more holistic manner.
You, and the FAQ you quoted, was talking about language-specification-simplicity. I was trying to make the discussion more cognizant of holistic-simplicity which means new complexity is created when one part is "simpler".
>There are reasonable ways to write code that largely avoids them
There are workarounds for everything, sure. Workarounds affect holistic-simplicty. Also, what's "reasonable" is subjective. In any case, I'm not convinced that language-spec-simplicity trumps holistic-simplicity.
It's just a different way of solving a problem. Labelling it a workaround is disingenuous if people are claiming they prefer writing code in that manner.
It's also incorrect to dismiss language complexity as specification complexity. One might just dismiss all of C++'s complexity as specification complexity. It ignores all the difficulties it adds to run-time, compilation (speed, correctness and compiler flexibility), incidental knock-on effects on other language constructs, external tools, syntactic simplicity, learning speed, code consistency and, as the article covers, just being itself a distraction from the real problem.
And if you write code in this manner anyway, the simplicity in the language makes a big difference.
> Labelling it a workaround is disingenuous if people are claiming they prefer writing code in that manner.
Well, I've never seen a Go expert espouse this opinion. Do you have a web article that actually says that? What I see is that many experts just carry on being productive in Go in spite of not having generics but that's a different position than actually preferring to copy&paste code or add a preproc code-gen (as Rob Pike once suggested as a workaround).
>And if you write code in this manner anyway, the simplicity in the language makes a big difference.
One can write in "that manner" whether generics was there or not. Existence of generics doesn't take away the ability to continue with suboptimal techniques such as copy & paste of redundant code for different data types.
> Do you have a web article that actually says that?
That says what? That they don't find not writing generics problematic? Rob Pike has said so himself. The article you've just read says exactly this[1].
[1] "With no generics, you are discouraged from making big, overly-general abstractions. This might be on purpose."
> One can write in "that manner" whether generics was there or not.
I have a feeling we're talking past each other. I'm saying that if you're not going to use generics, there's no point paying the costs of having generics. Not paying the cost means you get a simpler language, which has run-on benefits I mentioned before.
I'm not saying that generics are bad, or that emulating generics with copy & paste is better than generics.
Go has generics. Channels and maps are generics. You just can't define any new ones. It should at least be possible to define things that work like channels and maps. Those are more like parameterized types than generics, and going all the way to generics may not be necessary.
The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.)
As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process.
Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash.
However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.