> So, in the keynote, Rob underlines again that there'll be no generics. Ever.
No. He said there were no plans for generics, which has been the story for some time. The official FAQ still states [0]:
> Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
It is my understanding that what Mr. Pike means by there being no plans for generic is in relation to the sentence
> We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
>No. He said there were no plans for generics, which has been the story for some time.
No, the official apologist story is: we will add them as soon as we find a way to avoid all tradeoffs of the 3 different approaches to generics.
And when asked how are they going to find this "magic bullet" solution since noone seems to be looking for it, some Go devs wrote HN comments to say that "we are looking into them [generics]".
I'm a little offended, because nobody admitted what Rob said at the conference -- and they even tried to convince us of the contrary. That was like 2-3 months ago.
He means "we are going to leave the language [alone], we are done [changing it]." There is no expectation that the community will change the language instead.
Lots of apps are better with C, not just with regards to latency sensitivity (e.g games).
E.g an app that would process a multimedia file offline (so latency is of no concern) still runs circles around most other languages if its done i C or C++.
And of course 90% or something of desktop apps are written in C/C++.
People act as all those apps, which is what we use everyday, don't exist: browsers, editors, media players, terminals, OSes, mailers, etc etc. Even web apps use those as their substrate.
AIUI the main reason for using C for multimedia processing is to have inline assembler to make the best use of SIMD; aside from that it's certainly possible to write a video transcoder in Haskell (I've seen it done, for ARM where there didn't used to be such powerful SIMD options available).
Sure, I don't disagree with those (and Fortran, Obj-C, up to Rust someday).
Just wanted to highlight that most desktop programs people use by the millions are in fact written in C/C++ (statistically) -- and it's not all about GC, web programming and services.
Sadly for too many user space applications that are better served with safer languages, having native compilers available, that tend to be ignored by many.
This is a point that folks new to Go often miss. I oftentimes see people compare "interface{}" to "Object" in Java, which is not true.
(If you don't believe me, note that not everything in Java is actually an Object - since there are multiple typekinds[0], that means that not every type can be used where Java expects to see an Object). That is part of the reason for the mess surrounding the so-called wrapper types like Integer (which are themselves neither objects (wrappers are passed by value, not reference) nor primitives (they are in most[1] cases unboxed to primitives, but are not themselves the same things as primitives).
Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly), which certainly didn't stop its popularity, it cannot be emphasized enough that the need for generics is dramatically reduced if one actually understands how to use interfaces idiomatically in Go and understands how they are different from "interfaces" in Java or other languages[2].
While I occasionally run into a situation in which Java-like generics would make things marginally easier, they're few and far between; interfaces bridge far more of the difference than non-Go programmers often realize. And has has been explained to death already (both at Gophercon and on the mailing list) - generics are not out of the question for a hypothetical Go 2, but there are going to be no more changes to the language syntax for Go 1.
[0] I counted either 5 or 6 at one point when I was using Java heavily in university, but that was several years ago so don't quote me on that exact number.
[1] emphasis on "most" - there are some very "fun" edge cases that you can find here!
[2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
> This is a point that folks new to Go often miss.
It's still not true that interfaces are generics, though.
> Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly)
But that was a big mistake in Java: they had to implement them using type erasure and primitives didn't work with them (due to backwards compatibility), and they had to duplicate the collections library to have non-generic and generic collections (again due to backwards compatibility).
> [2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
I don't think the difference is that stark—interfaces in Java and interfaces in Go are essentially the same thing. The facts that all values can be wrapped in an interface (which is also true for C#, I believe) and that interface matching is structural instead of nominal are relatively minor.
Path to getting generics thus becomes:
1. A preprocessor that eats ggo (generic go) files and emits go. This is is like the original C++ which translated to C for compilation.
2. Someone integrates ggo into go to speed it all up.