This statement, part of the standard Go talking points, seems to be designed to persuade the unsure to give the language a chance, "and generics will be around later once we figure it out." Not likely.
I think the designers know that no perfect shining implementation of generics--compatible with all of Go's existing design decisions--is going to arise deus ex machina after eluding researchers for all these years.
There has been some talk, but it's mixed in with a lot of noise too.
I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea. I think this is more along the lines of how can we pragmatically introduce generics without messing up too bad. From what I've seen, I personally think some form of templating has the most promise (though I am far from qualified to actually comment on its viability).
That already happened. In 1976. There is simply no excuse for this disingenuous "oh but go is magic and special and can't do it the same way everyone else can" nonsense. If people want that argument to be taken seriously, then they need to start offering actual specific problems with parametric polymorphism as it would apply to go. Not just saying "we're special".
Implementing generics requires tradeoffs of some sort -- compile-time and size, runtime efficiency, or language-complexity. The creators didn't want to accept any of these compromises, at least for the initial release of go.
Really, if you have a language, compiler, and operating systems designer of the caliber of Rob Pike saying that generics introduce a lot of issues, I'm going to need some damned good evidence to the contrary.
"He also co-developed the Blit graphical terminal for Unix; before that he wrote the first window system for Unix in 1981. Pike is the sole inventor named in AT&T's US patent 4,555,775 or "backing store patent" that is part of the X graphic system protocol and one of the first software patents. [1]
Over the years Pike has written many text editors; sam and acme are the most well known and are still in active use and development.
Pike, with Brian Kernighan, is the co-author of The Practice of Programming and The Unix Programming Environment. With Ken Thompson he is the co-creator of UTF-8. Pike also developed lesser systems such as the vismon program for displaying images of faces of email authors."
Yeah, some amateur engineering right there. My point still stands; heuristically I have every reason to believe an extremely competent arquitect and designer who is involved in good faith on this project over a random commententer who can't be bothered to assess the evidence.
No one is denying that C and C++ have many problems. At the same time though, many of those problems have been solved in other languages (both older and newer than C++).
You don't need to believe anyone, that is the whole point. You are trying to turn it into "some guy's opinion vs the glorious and all-knowing rob's opinion". It is not a question of opinion, it is one of fact. Again, this problem was solved in 1976. ML is very old. Go read the papers on parametric polymorphism.
As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.
Where? I can find nothing of the sort. And given that we have proof otherwise (compare D to go for example) it seems likely that you are choosing to interpret "some languages made their compilers slower" with "parametric polymorphism must make a compiler slower".
most heavy users are self selected.
Outsiders may have suggestions for improvements, they may even be outsiders because they would like to see those suggestions realized, but when is that ever not the case?
Plus, something of this magnitude may need to be in a theoretical go2, so they can break whatever needs to be broken.
That's the party line. And I, for one, don't believe that.
Go has been going for what, 3 years? And a couple more internally IIRC. And not only they came up with nothing with regard to generics as of now, there's also no research or initiative has been started that anybody knows of.
So how exactly are they supposed to "find an implementation that fits within the language design goals"? By some kind of satori?
The language designers have not ruled out generics, and are fully open to providing them at some point. The issue is that they have yet to find an implementation that fits within the language design goals.
Yes, if you jump on the mailing list, and propose that they somehow "use" .NETs generics, and you actually have no idea how that would be implemented, or impact the compiler and runtime, you're not going to be greeted cordially. This happens fairly frequently, and is probably why people think the community is totally against generics.
The Go team wants generics, when they find the right way to handle them within the language. In the meantime, most heavy users seem to agree that lack of generics is better than poor generics.