5 ms·

I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.

by bitL 6y ago

tptacek 6y ago
It remains a selling point, and a concern for some Go developers. There's a lot of cognitive overhead in pervasively-parameterized codebases, and many developers would rather spend their cycles thinking about their algorithms or their problem domain rather than following extra layers of indirection. I'm psyched to see generics arrive, but (I say this a lot) I write about as much Rust as I do Go these days, and there is definitely a cost to pervasive generics. I hope Go retains most of its original spirit, while at the same time making it easy for some people to write red-black trees or whatever.
- jacques_chester 6y ago
  In practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.
  - tptacek 6y ago
    How do you figure? Python 3 isn't compatible with Python 2.
    - striking 6y ago
      I think that's the point of the reply, that we'll get codebases that aren't mutually compatible due to a resistance of or lean towards using generics. I'm not so certain that that's the case, but it is an interesting position nonetheless.
      - Thaxll 6y ago
        There is no such thing in Go since the language / runtime is very stable / backward compatible.
        striking 6y ago
        I think you may have missed the thrust of the earlier comment (which is that some developers may elect to never use libraries that use generics, whereas some developers may prefer libraries that use generics, and it could cause a schism in the community without being a necessarily language-level-breaking change), but it's also worth noting that Go absolutely has broken tooling through a language update in the past (https://github.com/golang/go/issues/24661 https://github.com/golang/go/issues/24661) and just generally does not have a particularly great history or coherent philosophy of good versioning practices and as such we should not just assume stability or backwards compatibility where there may not be any.
        tptacek 6y ago
        What's a major Go project that had to be ported, or maintained in two separate versions or branches, in order to target two different versions of the Go language itself? I don't think the Python comparison is particularly apt, whatever our other concerns about Go stability might be.
    - deleted 6y ago
      [deleted]
    - jacques_chester 6y ago
      In a social/cultural sense, rather than a purely technical sense. Old Busted C++ vs Modern C++ might have been a better example. Pre-generic and post-generic codebases will likely play awkwardly together, with lots of boxing between generics and interface{}. Folks who prefer generics will start to wrap or recreate popular existing libraries in the generic style. It'll be a constant drag on everything. Of course I may be wrong and the community might embrace the proposal whole-heartedly. But I won't hold my breath. Dismissing generics has been a gopher shibboleth for years and years.
- potta_coffee 6y ago
  Go's simplicity is definitely a big selling point for me.
- brundolf 6y ago
  > there is definitely a cost to pervasive generics I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse. I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up.
  - throwaway894345 6y ago
    > I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up. I agree with this a lot. Relatedly, Go has this nice property that code tends to be pretty 'standard' regardless of who wrote it (facilitates reading and writing). I hope the additional expressiveness that comes with generics doesn't harm this 'standardization' property of the ecosystem. > I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse I wonder if this is a consequence of TypeScript's breezy generics or if it's because people are now adding types to the egregiously abstract things they were already doing in JS.
    - brundolf 6y ago
      I would guess the driving factor is TypeScript's powerful inference capabilities. You can write generic functions all over the place, with multiple (sometimes interrelated!) type parameters, and you rarely have to pass explicit type arguments when calling anything. TypeScript will just figure it out. This removal of overhead when using complex types probably makes people less averse to creating them in the first place. Rust has a similar story.
- stefan_ 6y ago
  Okay, but it's Rust that is going the Boost template metaprogramming route?
- majewsky 6y ago
  > There's a lot of cognitive overhead in pervasively-parameterized codebases The lack of generics leads to occasional excesses in code generation (-cough- k8s/client-go -cough-) which can be even worse. I suspect that observing this in practice lead the Go core team to be more receptive to generics proposals.
- dcu 6y ago
  let's hope generics doesn't become a over(ab)used feature, that'd make the code harder to read and my experience harder to maintain, especially because when you need to fix something it takes a lot of time getting in context so you can actually write the code for the fix. I mostly write Go these days and haven't found many use cases where generics are needed but there are definitely cases where they would make the code nicer.
geodel 6y ago
Main selling point on their website?
randomdata 6y ago
When was that? The Go team has been working on generics since before 1.0, with numerous (failed) proposals along the way, and always said they would come when a suitable implementation was found; if ever found. That they wouldn’t compromise the language for a poor implementation of generics, just to have generics, may have been considered a selling feature?
- deleted 6y ago
  [deleted]
anamexis 6y ago
Language Design FAQ, November 2009: > Why does Go not have generic types? > 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. > This remains an open issue. https://web.archive.org/web/20091115211116/http://golang.org/doc/go_lang_faq.html https://web.archive.org/web/20091115211116/http://golang.org...
- povik 6y ago
  I remember reading that answer and having greater confidence in the language's designers as a result.
stunt 6y ago
I think much of the enthusiasm for Go comes from the fact that as a *compiled language*, it's easy to use and learn, and has a modern standard library. What attracts most of the developers is that they can deploy a binary with reasonable performance. That's why you see many PHP and Ruby developers loving it. I don't think an interpreted language with Go's design choices would be as popular. Therefore, I don't think adding Generics is going to harm.

I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.

by bitL 6y ago

I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.

It remains a selling point, and a concern for some Go developers. There's a lot of cognitive overhead in pervasively-parameterized codebases, and many developers would rather spend their cycles thinking about their algorithms or their problem domain rather than following extra layers of indirection. I'm psyched to see generics arrive, but (I say this a lot) I write about as much Rust as I do Go these days, and there is definitely a cost to pervasive generics. I hope Go retains most of its original spirit, while at the same time making it easy for some people to write red-black trees or whatever.

jacques_chester 6y ago
In practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.
- tptacek 6y ago
  How do you figure? Python 3 isn't compatible with Python 2.
  - striking 6y ago
    I think that's the point of the reply, that we'll get codebases that aren't mutually compatible due to a resistance of or lean towards using generics. I'm not so certain that that's the case, but it is an interesting position nonetheless.
    - Thaxll 6y ago
      There is no such thing in Go since the language / runtime is very stable / backward compatible.
      - striking 6y ago
        I think you may have missed the thrust of the earlier comment (which is that some developers may elect to never use libraries that use generics, whereas some developers may prefer libraries that use generics, and it could cause a schism in the community without being a necessarily language-level-breaking change), but it's also worth noting that Go absolutely has broken tooling through a language update in the past (https://github.com/golang/go/issues/24661 https://github.com/golang/go/issues/24661) and just generally does not have a particularly great history or coherent philosophy of good versioning practices and as such we should not just assume stability or backwards compatibility where there may not be any.
        tptacek 6y ago
        What's a major Go project that had to be ported, or maintained in two separate versions or branches, in order to target two different versions of the Go language itself? I don't think the Python comparison is particularly apt, whatever our other concerns about Go stability might be.
  - deleted 6y ago
    [deleted]
  - jacques_chester 6y ago
    In a social/cultural sense, rather than a purely technical sense. Old Busted C++ vs Modern C++ might have been a better example. Pre-generic and post-generic codebases will likely play awkwardly together, with lots of boxing between generics and interface{}. Folks who prefer generics will start to wrap or recreate popular existing libraries in the generic style. It'll be a constant drag on everything. Of course I may be wrong and the community might embrace the proposal whole-heartedly. But I won't hold my breath. Dismissing generics has been a gopher shibboleth for years and years.
potta_coffee 6y ago
Go's simplicity is definitely a big selling point for me.
brundolf 6y ago
> there is definitely a cost to pervasive generics I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse. I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up.
- throwaway894345 6y ago
  > I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up. I agree with this a lot. Relatedly, Go has this nice property that code tends to be pretty 'standard' regardless of who wrote it (facilitates reading and writing). I hope the additional expressiveness that comes with generics doesn't harm this 'standardization' property of the ecosystem. > I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse I wonder if this is a consequence of TypeScript's breezy generics or if it's because people are now adding types to the egregiously abstract things they were already doing in JS.
  - brundolf 6y ago
    I would guess the driving factor is TypeScript's powerful inference capabilities. You can write generic functions all over the place, with multiple (sometimes interrelated!) type parameters, and you rarely have to pass explicit type arguments when calling anything. TypeScript will just figure it out. This removal of overhead when using complex types probably makes people less averse to creating them in the first place. Rust has a similar story.
stefan_ 6y ago
Okay, but it's Rust that is going the Boost template metaprogramming route?
majewsky 6y ago
> There's a lot of cognitive overhead in pervasively-parameterized codebases The lack of generics leads to occasional excesses in code generation (-cough- k8s/client-go -cough-) which can be even worse. I suspect that observing this in practice lead the Go core team to be more receptive to generics proposals.
dcu 6y ago
let's hope generics doesn't become a over(ab)used feature, that'd make the code harder to read and my experience harder to maintain, especially because when you need to fix something it takes a lot of time getting in context so you can actually write the code for the fix. I mostly write Go these days and haven't found many use cases where generics are needed but there are definitely cases where they would make the code nicer.

geodel 6y ago

Main selling point on their website?

randomdata 6y ago

When was that? The Go team has been working on generics since before 1.0, with numerous (failed) proposals along the way, and always said they would come when a suitable implementation was found; if ever found. That they wouldn’t compromise the language for a poor implementation of generics, just to have generics, may have been considered a selling feature?

deleted 6y ago
[deleted]

anamexis 6y ago

Language Design FAQ, November 2009: > Why does Go not have generic types? > 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. > This remains an open issue. https://web.archive.org/web/20091115211116/http://golang.org/doc/go_lang_faq.html https://web.archive.org/web/20091115211116/http://golang.org...

povik 6y ago
I remember reading that answer and having greater confidence in the language's designers as a result.

stunt 6y ago

I think much of the enthusiasm for Go comes from the fact that as a *compiled language*, it's easy to use and learn, and has a modern standard library. What attracts most of the developers is that they can deploy a binary with reasonable performance. That's why you see many PHP and Ruby developers loving it. I don't think an interpreted language with Go's design choices would be as popular. Therefore, I don't think adding Generics is going to harm.