It seems like you’d have valuable feedback given that it’s a “showstopper” for you.
- 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.
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 enables 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.
Yep, assembly is less convenient than Go, but it doesn't mean you can't write programs using assembly.
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.
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.
... 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?
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.
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"?
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.
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.
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.
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.
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...
> 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 :).
"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.
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.
It's not rocket science.
And because it's 2017.
Why do we need anything beyond assembler?
Then you'll wish you had generics. :)
I remember when Java started to have generics in 1.5. It was very hard to go back to 1.4 after having used that. I feel that I just can't program without them any longer.
It's a small superset of Go that allows you to call map/filter/reduce methods on any slice. It's not true generics (you can't define your own generic functions or types) but it covers the most common use case for me: declarative data processing.
If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations that nobody else in the world understands, and your project fails but hey -- at least you have a dope, terse, generic implementation -- totally rad.
Depending how they're implemented, you might not have to use them (even via libraries). Not using the language altogether is a bit dramatic.
This is my beef with JavaScriot these days... They introduced a slew of new, in my opinion insane, control structures, and while I can avoid them in my code, they are still slowly polluting my dependencies, and adding obscure runtime requirements for my projects.