4 ms·

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, jus

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.
randomdata 9y ago
There are many different ways to provide generics (templates, typeclasses, etc.), each with their own pros and cons. It's not simply a matter of "add generics". And what solution they do come up with is going to bring the given cons those who would be better served by a different generics solution. The Go team have been long criticized for choosing the option that fits Google, but not the rest of the world. This seems like their attempt to think about what others are doing with the language, beyond their insular experience, so they don't end up with something that fits Google perfectly but falls apart everywhere else. If they don't take the time to learn how people intend to use generics in Go, the best solution for Google, and Google alone, is what we will get.
- lomnakkus 9y ago
  Then they should ask for that instead. It's not unreasonable to ask "how do we implement this in the best way?", but I'll note a) that's not what was asked, and b) I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"?
  - randomdata 9y ago
    > "how do we implement this in the best way?" They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request. > I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. I didn't say they need special generics. I said the approach that works best at Google may not be the best approach for the population at large. If Google is best served by C++-style generics, while the community as a whole would be better served by Haskell-style generics, why just jump in and do it the C++ way before seeing how others might want to use it? > Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"? Because they are trying to avoid the mistake of using one datapoint like Go has struggled with in the past? They know what works in Google, but that doesn't necessarily work for everyone else. See: Package dependencies, among many.

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.

randomdata 9y ago

There are many different ways to provide generics (templates, typeclasses, etc.), each with their own pros and cons. It's not simply a matter of "add generics". And what solution they do come up with is going to bring the given cons those who would be better served by a different generics solution. The Go team have been long criticized for choosing the option that fits Google, but not the rest of the world. This seems like their attempt to think about what others are doing with the language, beyond their insular experience, so they don't end up with something that fits Google perfectly but falls apart everywhere else. If they don't take the time to learn how people intend to use generics in Go, the best solution for Google, and Google alone, is what we will get.

lomnakkus 9y ago
Then they should ask for that instead. It's not unreasonable to ask "how do we implement this in the best way?", but I'll note a) that's not what was asked, and b) I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"?
- randomdata 9y ago
  > "how do we implement this in the best way?" They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request. > I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. I didn't say they need special generics. I said the approach that works best at Google may not be the best approach for the population at large. If Google is best served by C++-style generics, while the community as a whole would be better served by Haskell-style generics, why just jump in and do it the C++ way before seeing how others might want to use it? > Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"? Because they are trying to avoid the mistake of using one datapoint like Go has struggled with in the past? They know what works in Google, but that doesn't necessarily work for everyone else. See: Package dependencies, among many.