3 ms·

> 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: > W

by Veedrac 11y ago

> 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.

jasode 11y ago
>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.
- Veedrac 11y ago
  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. > Also, what's "reasonable" is subjective. I fully agree.
  - jasode 11y ago
    > 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.
    - Veedrac 11y ago
      > 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.
Animats 11y ago
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.

by Veedrac 11y ago

jasode 11y ago

>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.

Veedrac 11y ago
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. > Also, what's "reasonable" is subjective. I fully agree.
- jasode 11y ago
  > 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.
  - Veedrac 11y ago
    > 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.

Animats 11y ago

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.