I think this is one of the really great things about Go. Some detractors ask "There is so much to be gained by having generics! What would be lost if Go had generics? Nothing! Ergo, Go is wrong to not have generics".
This line of argument is flawed. Go curbs the ability of people to write crazy (and ultimately mentally expensive) abstractions. The lack of generics in Go is very a good thing. Especially when it comes to collaborating on a large unfamiliar code base.
I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. If there isn't, maybe I'm trying to solve the wrong problem, or it is the wrong language for the task.
If anything, generics reduce the mental expense of reading code, because if a container has a generic value type I know that it isn't going to be doing something interesting to those values behind the scenes.
Generics may not be the correct solution, but I would really like a way to make collections which are general enough to be used by any datatype. As of now, I cannot do that without doing the typical `interface{}` approach.
The built-in data structures + channels are able to handle this, but if I just want a set of elements, what do I do? Make a `map[foo] bool`? If I see such a piece of code in an unfamiliar code base, I have no idea whether to test for key existence or whether I have to test whether the bool is true. A generic set would leave me puzzled and type unsafe[1]: What types could possibly exist in this set? A set of foos is not that hard to comprehend, and is in fact very much more straightforward to understand than a generic set, which in unfamiliar code may contain anything, or a mapping from foos to bools.
[1]: Rob Pike mentions in http://www.youtube.com/watch?feature=player_detailpage&v... that type safety is of high importance for Golang, but how does one achieve that if all the different datatypes I implement/need use `interface {}` where I have to cast all values afterwards? That seems very type unsafe, from where I stand.
Your puzzling "generic set" isn't what is usually meant by a generic set in a statically typed language.
A generic set would be defined disregarding the type of its elements: "set of ?s". However, a single instance of a generic set would only be allowed to contain members of a single type: "set of foos". This is called parametric polymorphism.
That's only true in a language with type inference and type aliases.
In Java, generics make your code completely unreadable, as content is buried in boilerplate.
Map<Converter<Comment,Post>,ReadyState<CommentEnum> ops;
for (Entry<Converter<Comment,Post>,ReadyState<CommentEnum> e: ops.entrySet()) { ...
In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.
Generics (outside of C++'s templates which are a pretty odd duck[1]) generate very little compiler costs and little to no runtime costs (depending whether they're erased or reified), unless you decide to (optionally) trade some added compiler costs for some runtime improvements by generating type-specialized collections behind the scenes.
[1] and their cost is seriously compounded by the rest of C++, D has C++-style generics with a far lower compilation cost
Depends what you're comparing against. If it's a poor man's generic implementation in current Go using interface{}, then obviously there would be no extra runtime overhead if the compiler generated that for you in a type safe manner; but compared to manually specialized collections or the built-in generic collections, there is quite a lot of runtime overhead. Whether the compiler costs are manageable or not is up for debate.
The built-in collections can remain built-in if that gets you off. Same deal for manually specialized collections, except those aren't generic, so they remain not generic.
I think those are both rather bad solutions; I want generics precisely because they can provide equal performance to the built-in collections without the obvious drawbacks of a limited set of primitives or manually copying code. I'm just saying that "very little compiler costs and little to no runtime costs" is somewhat misleading, because there are significant runtime costs compared to those alternatives; Go needs code generation based generics, which are certainly doable, but incur significant complexity and runtime design issues.
> I want generics precisely because they can provide equal performance to the built-in collections
That is most definitely not the core use case for generics. They can be lifted into type-specialized collections, but the core point of generics is type safety.
Fair enough. Although my priorities somewhat differ from the norm, the document you criticized elsewhere does cite runtime overhead as a significant obstacle.
> the document you criticized elsewhere does cite runtime overhead as a significant obstacle.
And as I noted in my criticism it is completely wrong in doing so: the runtime overhead it notes is boxing in Java, ascribing it to generics.
But boxing is not a property of java's generics, it's a property of java's collections, java collections have required boxing value types since the first release (~1996), generics were only introduced in 2004. The boxing in java collections is orthogonal to generics.
In fact, one of the properties of C#'s reified generics is that it allows the compiler and runtime to avoid object (boxed) collections when it can use unboxed collections for value types.
True. The author is smart, and I would like to believe that he knew that reified unboxed collections would solve the space problem, but possibly be even worse than Java in time, since there is no JIT to inline repeated virtual calls to the same target. I can't guarantee that he did. ;p
Furthermore, other languages seem to have got this right without the fabled runtime/compiler costs that the Go authors seem to talk about (see D for instance). What's funny is that there are runtime costs today in Go that could have been resolved by using generics. All interface calls are virtual calls, and cannot be inlined.
> No one disputes that.
Citation needed. I read and heard from many people that do.
I can't cite my claim that "no one" does something. I'm happy to see any example you provide of the Go team/nuts saying that generics are a bad language idea.
C++ templates aren't generic (or more specifically, aren't parametric) for a few reasons, one of which being that they contain a hidden overloading mechanism.
I have to say, I love some of the principles of Haskell. I am a novice though and I currently don't stand a chance of picking up and hacking on a project without serious amount studying.
However, with a cursory glance at Go, I was able to be productive in it and hack on the go compiler and runtime itself.
Maybe this is more a statement about how little I know about functional languages or some of the theoretical techniques used in Haskell.
Whilst my mortal brain comes to grips with Haskell I am being quite productive in Go. I have learned a lot on the way, too.
Whether by design or accident, Go is filling the use case of "you tried Python but performance wasn't good enough". People will bring up cases like "you can't write a generic map function, or tree data structures!", but Go isn't the language for those things. In Go, you would just use a for loop or a dictionary-based map. If your program gets to the point where that no longer cuts it, then it's time to move on to a different language.
It seems to have been by accident, as they were originally designing it to be a "systems" programming language to take on C++. What eventually happened is that most(?) Go programmers came from Python, Ruby, and other scripting languages.
> In Go, you would just use a for loop or a dictionary-based map. If your program gets to the point where that no longer cuts it, then it's time to move on to a different language.
Really? I thought the reason Go didn't have generics is because they couldn't decide on an implementation that met their goals? That is, was quick and didn't emit a ton of code.
Russ Cox, one of programmers working on Go, described the dilemma as: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times?"
My god, this is such completely dishonest bullshit strawman I'm impressed he had the balls to post that garbage. Java's boxing does not come from its generics, it's the other way around (java's non-Array collections have never been able to hold unboxed values), and C++'s template are pretty much unique in their complexity (and definitely not what PL people think about when talking about generics) and compounded by all the rest of C++'s baggage (D has C++-style templates and is nowhere as slow to compile).
And his reaction to comments (that is, his complete failure to acknowledge how huge a strawman his original post is, and complete absence of response to any mention of C#, Eiffel, Ada, Haskell, MLs and others)... that is supposed to be a defense of goteam's thought process?
I'm super pro generics and love me some Haskell and ML. However, generics really do have a cost. Since the size of the objects in a generic container can vary, you either need to take the ML route of making everything a pointer (which add runtime cost) or the C++ (yeah, not really generics, but still) route of duplicating the code for every size object you store in the container. While I think Go made the wrong choice with generics, I understand their thought process.
I'm curious what the cost would be of implementing generics by having an (implicit) parameter for the element size. It would certainly be a bit slower than the fully specialized version, but it avoids boxing and doesn't duplicate code.
Unfortunately, that is their thought process. I find it hard to believe Rob, Russ, etc actually genuinely have never heard of ML, but everything they ever say on the issue suggests that is the case. And when people keep showing them "hey look, this problem was solved 30 years ago!" they just outright ignore them and don't acknowledge it.
>I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them.
Yes there is. Involving more code, less DRY, or loss of type safety.
I don't think you intended that as a preface to your flawed argument, but it worked out well. No, the lack of parametric polymorphism is not a good thing. You are losing simplicity, not gaining it.
This line of argument is flawed. Go curbs the ability of people to write crazy (and ultimately mentally expensive) abstractions. The lack of generics in Go is very a good thing. Especially when it comes to collaborating on a large unfamiliar code base.
I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. If there isn't, maybe I'm trying to solve the wrong problem, or it is the wrong language for the task.