5 ms·

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they do

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

Touche 9y ago
Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.
- Spiritus 9y ago
  Did you even read the blog post? Such feedback was explicitly asked for.
  - AaronFriel 9y ago
    I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable. What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind? To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems? I doubt it.
    - weberc2 9y ago
      Off topic, but any chance UNI is your alma mater? I think we may have been there at the same time, judging by your name and some of your comments.
      - AaronFriel 9y ago
        Aye.
  - lomnakkus 9y ago
    Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. - To give a sound account for the currently-magic built-in types. That should be enough, frankly, but I'm sure I could come up with more if I were to spend 5 more minutes on it... Can we stop pretending that they don't know of any compelling use cases now?
    - Spiritus 9y ago
      I was merely suggesting to indulge the author, especially now that generics might actually happen.
      - cyphar 9y ago
        The problem is that the community did indulge the author and the other Go maintainers 5 years ago and their was an apparent refusal to see lack-of-generics as an issue, almost as though Turing-completeness was sufficient justification to not include them. "Find us examples and show us so we can ponder this further" is incredibly condescending after we did that 5 years ago and they decided to stall (or to use the author's term, "wait") on the issue. Honestly I think it might be too late for generics to be added, because the large body of existing interfaces aren't generic and likely would have a very high transition cost.
        lomnakkus 9y ago
        (A bit late to your comment, but I found it valuable:) It's actually a classic bulshitting tactic by people who have no actual argument. Effectively, it's "well, we'll defer a choice until we can PROVE that decision X is PERFECT in EVERY way." That's not to say: IF there's a real, quantifiable doubt, then by all means, continue to discuss (but preferably set time limits), but to do that you MUST set out precisely what the problems are, what potential solutions could (and couldn't) be, etc. etc. Not just vague "this feels wrong" objections.
coldtea 9y ago
Because I like both reusable implementations of algorithms across compatible types AND type safety. It's not rocket science. And because it's 2017.
the_mitsuhiko 9y ago
The benefits of generics are well understood.
- Spiritus 9y ago
  So why is he requesting feedback on the matter?
  - AaronFriel 9y ago
    Bad faith.
  - ryeguy 9y ago
    That's what we're all trying to figure out.
abiox 9y ago
> for what use case(s) i almost feel this is like asking bjarne what use cases there are for 'classes' in c-with-classes. it's a structural language change that (depending on implementation details) can have sweeping ramifications on how one writes code. type parameterization allows for the expression of algorithms, idioms and patterns wholly or partially separate from concrete type details. i'm sure others can better sell the topic though.
littlestymaar 9y ago
Not the GP, but you can think about generics as a better kind of interfaces : - performance wise: no dynamic dispatch, means no virtual function call, means faster code. - type safety: let say I want a data structure that can store anything but everything in it must be the same type. You just can't do that with Go's current type system without introspection (which is cumbersome and really slow). Generics already exists in Go : maps, slices and channels and generic, and it was mandatory for performance reason. The problem of not having generics is that the community can't build its own implementation of useful data structures : for instance, until the last release Go lacked a thread-safe map. That's fine, let's use a library for that … Nope, can't implement that because, “no generics”. Generics are rarely useful in your own code, but they allow people to create good abstractions in their libraries. Without generics, the ecosystem growth is limited.
- brandonbloom 9y ago
  > you can think about generics as a better kind of interfaces No, you can't, because generics don't provide the key feature of interfaces: run-time dynamism. You could make a case that static polymorphism and dynamic polymorphism could be accomplished by a single mechanism, as traits do in Rust, but you can't say generics are "better" than interfaces, since they solve a different set of problems, with different implementation strategies, despite related theoretical foundations. > The problem of not having generics is that the community can't build its own implementation of useful data structures This is not true either, although it is true that it is harder to do this sort of thing in Go, the result may in fact not be as fast as you can achieve with monomorphisation, and you may have to write more code by hand. The "trick" is the Go model is to provide an interface (which yes, potentially unnecessarily uses a dynamic mechanism) to implement indirect operations. For example the Swap function of https://golang.org/pkg/sort/#Interface https://golang.org/pkg/sort/#Interface enables https://golang.org/pkg/container/heap/#Interface https://golang.org/pkg/container/heap/#Interface - which is a reusable data structure. Compiler-level static-generics for slices and arrays, combined with indirecting through array indexes, enables you to avoid boxing when instantiating the heap interface. The data structure can be instantiated with an interface once, so there is no dynamic lookup for heap operations, but there is still a double indirect call. Yes, this is less convenient than proper generics, but this doesn't mean you can't do these things. Furthermore, I've never actually needed to do this outside of sorting (which is, absolutely, is annoying) in large projects. Almost every time I need a specialized data structure, I usually need it for performance reasons, and so hand-specializing for my needs tends to be worthwhile anyway. > Generics are rarely useful in your own code, but they allow people to create good abstractions in their libraries. I'd like to see something like templates or generics for Go, but I definitely don't want Java-style "fake" generics without code specialization. Furthermore, I found that the vast majority of generics-heavy libraries back in my C# days were more trouble than they are worth, despite meaningful opportunities for better performance with value types. Copy/paste almost always resulted in a better outcome.
xenadu02 9y ago
Create an ordered set or bloom filter type for Go and let us know how you make out.
slantedview 9y ago
> The question is _why_ do you need generics Why do we need anything beyond assembler?
deleted 9y ago
[deleted]
GenericsMotors 9y ago
Try implementing LINQ in Go, while using no runtime type assertions at all and maintaining compile-time type safety (ie: no interface{}). Then you'll wish you had generics. :)

Touche 9y ago

Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.

Spiritus 9y ago
Did you even read the blog post? Such feedback was explicitly asked for.
- AaronFriel 9y ago
  I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable. What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind? To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems? I doubt it.
  - weberc2 9y ago
    Off topic, but any chance UNI is your alma mater? I think we may have been there at the same time, judging by your name and some of your comments.
    - AaronFriel 9y ago
      Aye.
- lomnakkus 9y ago
  Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. - To give a sound account for the currently-magic built-in types. That should be enough, frankly, but I'm sure I could come up with more if I were to spend 5 more minutes on it... Can we stop pretending that they don't know of any compelling use cases now?
  - Spiritus 9y ago
    I was merely suggesting to indulge the author, especially now that generics might actually happen.
    - cyphar 9y ago
      The problem is that the community did indulge the author and the other Go maintainers 5 years ago and their was an apparent refusal to see lack-of-generics as an issue, almost as though Turing-completeness was sufficient justification to not include them. "Find us examples and show us so we can ponder this further" is incredibly condescending after we did that 5 years ago and they decided to stall (or to use the author's term, "wait") on the issue. Honestly I think it might be too late for generics to be added, because the large body of existing interfaces aren't generic and likely would have a very high transition cost.
      - lomnakkus 9y ago
        (A bit late to your comment, but I found it valuable:) It's actually a classic bulshitting tactic by people who have no actual argument. Effectively, it's "well, we'll defer a choice until we can PROVE that decision X is PERFECT in EVERY way." That's not to say: IF there's a real, quantifiable doubt, then by all means, continue to discuss (but preferably set time limits), but to do that you MUST set out precisely what the problems are, what potential solutions could (and couldn't) be, etc. etc. Not just vague "this feels wrong" objections.

coldtea 9y ago

Because I like both reusable implementations of algorithms across compatible types AND type safety. It's not rocket science. And because it's 2017.

the_mitsuhiko 9y ago

The benefits of generics are well understood.

Spiritus 9y ago
So why is he requesting feedback on the matter?
- AaronFriel 9y ago
  Bad faith.
- ryeguy 9y ago
  That's what we're all trying to figure out.

abiox 9y ago

> for what use case(s) i almost feel this is like asking bjarne what use cases there are for 'classes' in c-with-classes. it's a structural language change that (depending on implementation details) can have sweeping ramifications on how one writes code. type parameterization allows for the expression of algorithms, idioms and patterns wholly or partially separate from concrete type details. i'm sure others can better sell the topic though.

littlestymaar 9y ago

Not the GP, but you can think about generics as a better kind of interfaces : - performance wise: no dynamic dispatch, means no virtual function call, means faster code. - type safety: let say I want a data structure that can store anything but everything in it must be the same type. You just can't do that with Go's current type system without introspection (which is cumbersome and really slow). Generics already exists in Go : maps, slices and channels and generic, and it was mandatory for performance reason. The problem of not having generics is that the community can't build its own implementation of useful data structures : for instance, until the last release Go lacked a thread-safe map. That's fine, let's use a library for that … Nope, can't implement that because, “no generics”. Generics are rarely useful in your own code, but they allow people to create good abstractions in their libraries. Without generics, the ecosystem growth is limited.

brandonbloom 9y ago
> you can think about generics as a better kind of interfaces No, you can't, because generics don't provide the key feature of interfaces: run-time dynamism. You could make a case that static polymorphism and dynamic polymorphism could be accomplished by a single mechanism, as traits do in Rust, but you can't say generics are "better" than interfaces, since they solve a different set of problems, with different implementation strategies, despite related theoretical foundations. > The problem of not having generics is that the community can't build its own implementation of useful data structures This is not true either, although it is true that it is harder to do this sort of thing in Go, the result may in fact not be as fast as you can achieve with monomorphisation, and you may have to write more code by hand. The "trick" is the Go model is to provide an interface (which yes, potentially unnecessarily uses a dynamic mechanism) to implement indirect operations. For example the Swap function of https://golang.org/pkg/sort/#Interface https://golang.org/pkg/sort/#Interface enables https://golang.org/pkg/container/heap/#Interface https://golang.org/pkg/container/heap/#Interface - which is a reusable data structure. Compiler-level static-generics for slices and arrays, combined with indirecting through array indexes, enables you to avoid boxing when instantiating the heap interface. The data structure can be instantiated with an interface once, so there is no dynamic lookup for heap operations, but there is still a double indirect call. Yes, this is less convenient than proper generics, but this doesn't mean you can't do these things. Furthermore, I've never actually needed to do this outside of sorting (which is, absolutely, is annoying) in large projects. Almost every time I need a specialized data structure, I usually need it for performance reasons, and so hand-specializing for my needs tends to be worthwhile anyway. > Generics are rarely useful in your own code, but they allow people to create good abstractions in their libraries. I'd like to see something like templates or generics for Go, but I definitely don't want Java-style "fake" generics without code specialization. Furthermore, I found that the vast majority of generics-heavy libraries back in my C# days were more trouble than they are worth, despite meaningful opportunities for better performance with value types. Copy/paste almost always resulted in a better outcome.

xenadu02 9y ago

Create an ordered set or bloom filter type for Go and let us know how you make out.

slantedview 9y ago

> The question is _why_ do you need generics Why do we need anything beyond assembler?

deleted 9y ago

[deleted]

GenericsMotors 9y ago

Try implementing LINQ in Go, while using no runtime type assertions at all and maintaining compile-time type safety (ie: no interface{}). Then you'll wish you had generics. :)