6 ms·

> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may wel

> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. 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. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly. Once the community could no longer be held back, the golang FAQ presented a very different position[1]: The Go 1.18 release added type parameters to the language. This permits a form of polymorphic or generic programming. 0 - https://web.archive.org/web/20170102202940/http://golang.org/doc/faq#generics https://web.archive.org/web/20170102202940/http://golang.org... 1 - https://go.dev/doc/faq#generics https://go.dev/doc/faq#generics

win311fwg 28d ago
Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. But not before an acceptable solution was found.
- ksec 28d ago
  Do we know if Go team is working in 2.0 release?
  - dolmen 28d ago
    We know they aren't. They have successfully been able to add major features such as generics without breaking 1.0 compatibility, and the trend is to continue than way. Well there is no major language feature in sight in fact. Also major figures of the Go team (Russ, Ian, Rob, Ken) are gone.
    - ksec 27d ago
      Oh I somehow completely missed Russ left. I was rather hoping there will be a version 2 from all the lessons they have learned.
- AdieuToLogic 27d ago
  Regarding generics (a.k.a. "templates"): > However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]: Notice that Robert said C was the starting point, not C++. I'm not certain but I believe he meant C proper, especially because Ken was there. But it's also true that, in the end, we didn't really start from C. We built from scratch, borrowing only minor things like operators and brace brackets and a few common keywords. In the end of course it came out quite different from either C or C++. More different even than many realize. I made a list of significant simplifications in Go over C and C++: ... - no templates ... 0 - https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
  - Mawr 26d ago
    C++ templates and Go generics are very much not the same thing.
potamic 28d ago
> Generics are convenient but they come at a cost in complexity in the type system and run-time. By run-time they mean compile-time? There shouldn't be a run-time penalty right? Also, is there some measure of the additional compilation cost now that generics has been added?
- neild 28d ago
  The “runtime” as in the compiler runtime which provides the scheduler, garbage collector, etc.
  - dolmen 28d ago
    The runtime also includes reflection, so preserving compatibility of the type system while adding generics was definitely a challenge, so adding generics to Go was definitely a great achievement.
mseepgood 27d ago
"May well be added at some point" it said and added they were at some point.
- AdieuToLogic 27d ago
  > "May well be added at some point" it said and added they were at some point. That is a very selective quote which does not reflect the context I provided. So I will extract a selective quote which negates the above: We haven't yet found a design that gives value proportionate to the complexity ...
  - Mawr 26d ago
    I don't know how you're reading the quotes you provide, they seem to directly contradict what you're saying.

win311fwg 28d ago

Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. But not before an acceptable solution was found.

ksec 28d ago
Do we know if Go team is working in 2.0 release?
- dolmen 28d ago
  We know they aren't. They have successfully been able to add major features such as generics without breaking 1.0 compatibility, and the trend is to continue than way. Well there is no major language feature in sight in fact. Also major figures of the Go team (Russ, Ian, Rob, Ken) are gone.
  - ksec 27d ago
    Oh I somehow completely missed Russ left. I was rather hoping there will be a version 2 from all the lessons they have learned.
AdieuToLogic 27d ago
Regarding generics (a.k.a. "templates"): > However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]: Notice that Robert said C was the starting point, not C++. I'm not certain but I believe he meant C proper, especially because Ken was there. But it's also true that, in the end, we didn't really start from C. We built from scratch, borrowing only minor things like operators and brace brackets and a few common keywords. In the end of course it came out quite different from either C or C++. More different even than many realize. I made a list of significant simplifications in Go over C and C++: ... - no templates ... 0 - https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
- Mawr 26d ago
  C++ templates and Go generics are very much not the same thing.

potamic 28d ago

> Generics are convenient but they come at a cost in complexity in the type system and run-time. By run-time they mean compile-time? There shouldn't be a run-time penalty right? Also, is there some measure of the additional compilation cost now that generics has been added?

neild 28d ago
The “runtime” as in the compiler runtime which provides the scheduler, garbage collector, etc.
- dolmen 28d ago
  The runtime also includes reflection, so preserving compatibility of the type system while adding generics was definitely a challenge, so adding generics to Go was definitely a great achievement.

mseepgood 27d ago

"May well be added at some point" it said and added they were at some point.

AdieuToLogic 27d ago
> "May well be added at some point" it said and added they were at some point. That is a very selective quote which does not reflect the context I provided. So I will extract a selective quote which negates the above: We haven't yet found a design that gives value proportionate to the complexity ...
- Mawr 26d ago
  I don't know how you're reading the quotes you provide, they seem to directly contradict what you're saying.