4 ms·

> ...how Go getting generics will change its position in the landscape. I think it'll have minimal immediate effect. It'll quieten the vocal ones, but being a

> ...how Go getting generics will change its position in the landscape. I think it'll have minimal immediate effect. It'll quieten the vocal ones, but being a pragmatic bunch of people, most golang users just won't care much, at least at first. No doubt libraries will adopt it over time. Other golang projects will slowly follow.

jeremyjh 7y ago
I think this is right. Few people will say "oh Go has generics let me start using it now". But at the same time we shouldn't underestimate the benefit improved libraries could have on adoption in the long-run. I've heard several people say they just are not happy with any ORM in the Go ecosystem, for example and I think that situation would improve significantly with generics.
- c-cube 7y ago
  That's hard to measure. If Go had sum types and generics I'd be more willing to give it a serious try , but in its current state I don't see myself writing complex algorithmic code in it. Maybe other people feel the same, especially among the crowd already used to static typing.
- erik_seaberg 7y ago
  I've been avoiding Go as much as possible as a poor use of engineering time, but I'll reconsider if they fix generics and error handling and comprehensions. Java 8 isn't outstanding (the JVM is!) but it's about where I put the bar for a tolerable language.
- throwaway894345 7y ago
  I disagree. I think there are tons of people who won’t touch Go because they can’t fathom programming without generics. I think lots of people will use the language and interact with lots of existing code and realize how far one can go with respect to type safety without ever touching generics. Unfortunately, I’m also afraid that this sea of newcomers will bring all of their paradigms to the Go ecosystem which is made possible by generics, and frankly the consistency that makes Go so productive will be lost. I like generics, but I’m afraid of the cost.
  - erik_seaberg 7y ago
    My favorite example is https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map, which should have been a typesafe drop-in replacement for map[K]V, but that isn't possible even within the standard library.
    - throwaway894345 7y ago
      Yeah, I tend not to write or use these data structures. If I want a concurrent map, I usually write my own anyway. It’s easier to add the locks I want than to keep track of how sync.Map thinks about locking a map. I understand that this attitude angers a lot of people who believe that everything should be as DRY as possible, but this way works better for me.
      - vardump 7y ago
        I don't know about sync.Map, but many concurrent maps don't require any locking (or require rarely). Protecting map with a lock is a very naive solution, it'll perform badly with a lot of concurrent writes.
        erik_seaberg 7y ago
        https://golang.org/src/sync/map.go https://golang.org/src/sync/map.go is not completely lock-free but yeah, I think it's trying to batch structural changes to the map (and atomic compare-and-set on existing entries) which isn't something I would rewrite casually. There's just no good reason that you can't reuse it without rewriting all call sites. []T and map[K]V and chan T should implement interfaces, everyone should always use those interfaces, and monomorphization should skip the runtime dispatch.

jeremyjh 7y ago

I think this is right. Few people will say "oh Go has generics let me start using it now". But at the same time we shouldn't underestimate the benefit improved libraries could have on adoption in the long-run. I've heard several people say they just are not happy with any ORM in the Go ecosystem, for example and I think that situation would improve significantly with generics.

c-cube 7y ago
That's hard to measure. If Go had sum types and generics I'd be more willing to give it a serious try , but in its current state I don't see myself writing complex algorithmic code in it. Maybe other people feel the same, especially among the crowd already used to static typing.
erik_seaberg 7y ago
I've been avoiding Go as much as possible as a poor use of engineering time, but I'll reconsider if they fix generics and error handling and comprehensions. Java 8 isn't outstanding (the JVM is!) but it's about where I put the bar for a tolerable language.
throwaway894345 7y ago
I disagree. I think there are tons of people who won’t touch Go because they can’t fathom programming without generics. I think lots of people will use the language and interact with lots of existing code and realize how far one can go with respect to type safety without ever touching generics. Unfortunately, I’m also afraid that this sea of newcomers will bring all of their paradigms to the Go ecosystem which is made possible by generics, and frankly the consistency that makes Go so productive will be lost. I like generics, but I’m afraid of the cost.
- erik_seaberg 7y ago
  My favorite example is https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map, which should have been a typesafe drop-in replacement for map[K]V, but that isn't possible even within the standard library.
  - throwaway894345 7y ago
    Yeah, I tend not to write or use these data structures. If I want a concurrent map, I usually write my own anyway. It’s easier to add the locks I want than to keep track of how sync.Map thinks about locking a map. I understand that this attitude angers a lot of people who believe that everything should be as DRY as possible, but this way works better for me.
    - vardump 7y ago
      I don't know about sync.Map, but many concurrent maps don't require any locking (or require rarely). Protecting map with a lock is a very naive solution, it'll perform badly with a lot of concurrent writes.
      - erik_seaberg 7y ago
        https://golang.org/src/sync/map.go https://golang.org/src/sync/map.go is not completely lock-free but yeah, I think it's trying to batch structural changes to the map (and atomic compare-and-set on existing entries) which isn't something I would rewrite casually. There's just no good reason that you can't reuse it without rewriting all call sites. []T and map[K]V and chan T should implement interfaces, everyone should always use those interfaces, and monomorphization should skip the runtime dispatch.