 |
| “I'm sorry, but no: Generics are a technical issue and are not a political one.” (comment) | ||
| recommended by 4 users | 2015 | rsc on: Go 1.5 max procs default | go | original thread | | ||
| rsc on May 29, 2015 | on: Go 1.5 max procs default | view on HN | ||
| 4 users recommended this comment. What they said: |
|
civility Jan 19, 2017 | on: Rust vs. Go | context
I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach. |
|
Zikes Mar 21, 2017 | on: Changes I would make to Go | context
It's absolutely a possibility for Go 2.0. There's a hard lock on Go 1.X compatibility, but per the link in my above comment the Go team is fielding proposals for Generic implementations. I also recommend reading Russ Cox's (Go core developer) HN comment: https://news.ycombinator.com/item?id=9622417 |
|
Cthulhu_ Oct 8, 2020 | on: Swift Algorithms | context
Because generics is a nontrivial problem to solve in languages and compilers; a really great comment that I bookmarked is here: https://news.ycombinator.com/item?id=9622417. I read elsewhere (can't find it now) just how much lines of code and language spec is dedicated to generics in Java. Right now, the Go spec + compiler chain are a lot simpler; adding generics would have made things a ton more complicated. Second, by first spending a lot of time perfecting the core language, understanding it, and resolving early issues, they have a much more stable base now to build generics on top of it. As the comment also implies, they take things slow and steady when it comes to Go; it's a language made to run core systems (e.g. at Google) for the next 30-50 years. |
|
throwaway34241 Jun 1, 2020 | on: Featherweight Go | context
It’s hard for me to believe that it is as simple as you suggest, considering the large amount of work put in by the Go team already, and the even larger amount of work put in by other programming language implementors to eventually arrive at various (different) design points. Work which often takes many years like C++ concepts. Not to mention the open invitation for concrete proposals on how to add them Go. You might find this post by one of the Go team members interesting: |
I'm sorry, but no: Generics are a technical issue and are not a political one. The Go team is not against generics per se, only against doing things that are not well understood and/or don't work well with Go.
There are deep technical issues that must be solved to fit the idea of generics into Go in a way that works well with the rest of the system, and we don't have solutions to those. I wrote on my blog about one issue years ago (http://research.swtch.com/generic), but there are others too. Even supposing you get past the problem on that page, the next thing you would run into is how to allow programmers to omit type annotations in a useful, easy-to-explain way. As an example, C++ lets you write make_pair(1, "foo") instead of make_pair<int, string>(1, "foo"), but the logic behind inferring the annotations takes pages and pages of specification, which doesn't make for a particularly understandable programming model, nor something the compiler can easily explain when things go wrong. And then there's a princess in another castle after that one I am sure.
We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make. As a demonstration, skim through most of http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... and see how long before you start to think "was this really the best way to do this?" (For example, http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypePa..., but note that the latter page is only one part of the FAQ, not the entire FAQ.)
To be very clear, we acknowledge this fact: there are definite disadvantages to not having generics. You either use interface{} and give up compile-time checking or you write code generators and complicate your build process. But there are also definite disadvantages to generics as implemented in existing languages, and there is a very large advantage to not compromising today: it makes adopting a better solution tomorrow that much easier.
As I said in the interview at http://www.pl-enthusiast.net/2015/03/25/interview-with-gos-r...:
> Go is more an engineering project than a pure research project. Like most engineering, it is fundamentally conservative, using ideas that are proven and well understood and will work well together. The research literature’s influence comes mainly through experience with its application in earlier languages. For example, the experience with CSP applied in a handful of earlier languages—Promela, Squeak, Newsqueak, Alef, Limbo, even Concurrent ML—was just as crucial as Hoare’s original paper to bringing that idea to practice in Go. Programming language researchers are sometimes disappointed that Go hasn’t picked up more of the recent ideas from the literature, but those ideas simply haven’t had time to pass through the filter of practical experience.
I believe generics is one of those ideas. It certainly needs at least one more iteration, possibly a few more than that.