Are there any plans to add generics yet, or do I still have to write a bunch of extra boilerplate functions in order to sort a list?
Also, speaking only for myself, I really like the language and its ideas, but that one thing it's missing makes it too annoying to write code in it. I'd like to see more people aware of this deficiency and putting pressure on the language's owners to fix that problem, so that I can start using it.
If there's another thread which talks about good and bad points of the Golang design then, by all means, bash the language as much as you like. But if there's something you don't like it doesn't mean you get a free pass to repeat yourself whenever something with Go in the title appears in HN, whatever it is. Context matters, you aren't helping anybody, just trolling.
Of course, you can do whatever you want, but that doesn't mean that the rest of us won't probably look at your comments thinking "Here come the generics whiners again" and look in the other direction. You are alienating your audience with your indiscriminate repetition.
And, if the disclaimer helps you, I'd like generics in Go, they are useful sometimes. I just don't see the point in such zealotry over something which is merely convenient.
But seriously, they may not implement generics out of spite or just to troll generics zealots.
Edit: remove ambiguity
now my code looks like "func map(x []T, f func(T) T)" and everybody's happy :)
type T1 generic type T2 generic
func Map(f func(T1) T2, s []T1) []T2
I can see that I am putting some people off with my commentary, but other people apparently got new information. Hard to say whether this is a win or loss on net. Time will tell, sooner or later.
Bringing that into a thread regarding a very cool set of examples regarding the core features of the language, isn't very constructive (at least IMO).
> Go is that _slim_, and that's good! Guaranteed you'll find use for Go in one system or the other...
I'm all for learning new programming languages, but if you're going to learn a new programming language, why not use one that has new ideas?
My point is that generics are not a new idea either, and plenty of languages offer them. Go is not meant (anymore) to replace C/C++/Java or even Rust. It will never have all the features of those, and probably should not.
But it seems impossible to have a HN discussion on Golang without part of the thread getting hijacked with "But generics!!!" This make no more sense to me than considering other languages incomplete because they don't generate static binaries.
Surely the exact same criticism could be leveraged at go proponents pointing out the exact same features they love every time, should discussions of Go simply stop until the next major release, and only new features (if any) be discussable?
This thread was started by someone complaining about lack of generics.
> should discussions of Go simply stop until the next major release, and only new features (if any) be discussable?
Why? Because there's no reasonable middle ground between "don't ever talk about Go until there's a release" and "hijack every thread about Go"?
Go hits some sweet spot, apparently, since some people are happier using it than anything else they had tried. If no "new ideas" are going to help them, why should they chose more "innovative" languages instead of Go?
Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts.
There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.
I also don't really have a lot of excitement about the prospect of solving problems by composing types in Go. For instance, to the best of my knowledge, Go does not have language support for sum types. It's not that I'd rather use continuations or callbacks -- I like powerful, expressive type systems to do, e.g., static enforcement of contracts -- it's just that I think that Go's type system isn't very expressive.
You're right, perhaps I'm totally misinformed about the language, and that lurking below there really is a way to do clear and clean things with types in Go. But everything I've seen points in the opposite direction, so at this point, though I have an open mind, I'd need more evidence to change my view.
Mark's point was that you can create an arbitrary wrapper type around another interface, so that the behaviors are composed. This is the most flexible way to do things. If there's already a wrapper type that does what you want, however, then you can simply use that. They are both examples of composition, and both "the Go-ic way to do it."
Composition is often overlooked by people who are fixated on other ways of doing things, like inheritance or generics. But in many ways, it's cleaner, since composition allows you to link together many modules without peeking inside.
It's funny that people have accepted the reality of dynamic languages, but can't seem to "get" the idea of statically typed language without generics. There isn't a troll comment in every Python article that it would be better with static typing. Type systems are a little bit like body armor-- development can be slower, but in exchanged you get a little more confidence in the program. People have accepted the idea of going naked, and the idea of medieval-style full plate armor, but the idea that you might want some type safety, but not go overboard often seems to fall on deaf ears.
Composition is great. It does not solve the same problem as generics. The reason people can't seem to "get" the idea of statically typed languages without generics is because static typing without parametric polymorphism is a painful experience.
I'm not opposed to the idea of finding some balance between static and dynamic typing -- Clojure type annotations seem interesting -- it's just that I don't like the way Go does it.
Of course, being Rob Pike, decreeing that authority and experience is more valuable than any (well-reasoned) complaints from other people is a very convenient stance for him to take; how many complainers are going to rival his résumé?
func (a ByAge) Len() int { return len(a) }
func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
And not having generics means that (as far as I can tell) people end up using a lot of `interface{}`. How does that increase safety?
More importantly, why would I want to use a language whose solution to the problem of "dealing with generic data" essentially boils down to "use a void*"?
There are too many indirections to follow manually. All I know is that the compiler will select some function that has conforming types. The compiler is very very smart. It knows all the incredibly complicated name resolution rules and it will use each one of them.
Unfortuntately I'm not as smart. Even after more than 20 years of using C++ I sometimes fail to anticipate which function the compiler decides to use. And that is not safe.
In fact it is less safe than casting interface{}, because that will at least fail fast at runtime instead of silently doing something unexpected.
I think Go needs some form of generics. Every statically typed language does. But after C++ I do understand the hesitation on the part of Go's creators.