Hacker News Reader

Comment by lomnakkus | Hacker News Reader

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?

View on HN

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.

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"?

> "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.

> 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.

Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy.

> 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?

OK, so you said they don't need a special generics, but then say that they do. I must not be understanding what you're trying to say. (If this is about choosing trade-offs, then see the other poster who talked about trade-offs. Executive summary: Not doing generics is also a trade-off.)

Also: ASK GOOGLE.

> 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.

You can't have it both ways. Either Google is important enough to it in a way that works for them, or the community is more important and they get to choose.

Anyway, I'm done with this conversation. I think we may be seeing this from viewpoints that are so different that it's pointless to continue.

I'm not sure how to argue constructively with someone who says "I'm not saying X, but..." and then immediately states a rephrasing of "X". I'm sure that's not what you think you are doing, but that's the way I'm seeing it, FWIW.

> Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy.

Maybe, but I don't know that we should be attacking someone's poor communication ability. I'm sure I've misunderstood at least one of your points too. Let's just focus on what was actually asked for: Use-case examples.

> OK, so you said they don't need a special generics, but then say that they do.

There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons.

If imperative programming is the best choice for Google, that doesn't mean the community wouldn't be better served by functional programming, so to speak. And when it comes to generics, there are quite a few different paradigms that can be used, and not easily mixed-and-matched. They are asking for use-cases to determine which generics paradigm fits not only the needs at Google, but the needs everywhere.

> Also: ASK GOOGLE.

The Go team is Google. They have asked Google. Now they are asking everyone else. I'm not sure how to make this any more clear.

> Either Google is important enough to it in a way that works for them, or the community is more important and they get to choose.

In the past Google was seen as the most important, and they have been widely criticized for it. This is them moving in a direction that favours the community. And they are still being criticized for it... Funny how that works.

> There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons.

Yes, thank you. Everybody in this thread already knows that. PICK ONE.

(EDIT: I should also add: Since Go is structually typed and has mutable variables, that should be a good indication of what to do and what not to do. See e.g. Java arrays, variance and covarince.)

> If imperative programming is the best choice for Google, that doesn't mean the community wouldn't be better served by functional programming, so to speak. And when it comes to generics, there are quite a few different paradigms that can be used, and not easily mixed-and-matched. They are asking for use-cases to determine which generics paradigm fits not only the needs at Google, but the needs everywhere.

And now you're trying to bring imperative vs. functional into this?

I think IHBT... and this really is my last comment in this thread. Have a good $WHATEVER.

> Yes, thank you. Everybody in this thread already knows that. PICK ONE.

They are picking one, based on the use-cases that will be given to them in the near future. I don't understand what your point is here.

> Since Go is structually typed and has mutable variables, that should be a good indication of what to do and what not to do.

That may be true, but the worst case scenario is that they learn nothing from the examples they get. You don't have to provide any if you feel it is a useless endeavour. If it gives them comfort, so be it.

> And now you're trying to bring imperative vs. functional into this?

It wasn't clear if you understood what I meant by there being different ways to provide generics. I struggled to write it as eloquently as I had hoped and the analogy was meant to bridge what gaps may have existed.

It's almost like communication can be difficult. Where have I see that before? Hmm...

(Just to end it. I was intrigued.)

> It's almost like communication can be difficult.

We can agree about that! :)

> Where have I see that before? Hmm...

Not sure what you mean (ironically?).

Have a good night :).

I was merely suggesting to indulge the author, especially now that generics might actually happen.

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.

(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.

Reply on news.ycombinator.com