7 ms·
Any updates regarding generics and error handling?
by zerr 11y ago
Any updates regarding generics and error handling?
- Thaxll 11y agoCould people stop trolling about generics on every Golang topics?
- zerr 11y agoThe Golang FAQ mentions from the day one that they are going to consider adding ge<censored>ics someday in the future. So I was wandering if there are any updates regarding this. I didn't expect such a fanboysm though...
- rsc 11y agoEven if there were news, it's certainly off topic for this post.
- andrewchambers 11y agoIf you ever implement it, I suggest a release on april 1st.
- artursapek 11y agoThat would be my favorite April Fools ever.
- kjksf 11y agoThe FAQ also says that Go 1 will not introduce backwards-incompatible changes. Generics would be such a backwards-incompatible change. So the answer to "are there generics in 1.x release" will always be "no". http://golang.org/doc/faq#What_is_the_status_of_the_project http://golang.org/doc/faq#What_is_the_status_of_the_project http://golang.org/doc/go1compat http://golang.org/doc/go1compat Go 2 is years away (if it even happens).
- zerr 11y ago>"are there generics in 1.x release" I've never asked this. Certainly it would have been a big news. I asked if there are any updates in general - any new thoughts, plans...
- chc 11y agoHow are generics backward-incompatible? They would obviously affect forward compatibility, but what previously valid programs would have to become invalid with the introduction of generics? (Incidentally, as an interesting contrast, this GOMAXPROCS default change will break some existing programs.)
- knodi 11y agoHow will GOMAXPROCS default change break existing programs?
- chc 11y agoPer the OP: "Increased parallelism could make bugs in racy programs more likely to cause crashes or other problems. The setting of GOMAXPROCS=1 may have thus far let those bugs go undetected. Raising it may therefore make buggy programs less reliable."
- ecnahc515 11y agoGOMAXPROCS isn't really a language feature, that's all implementation specific AFAIC.
- prodigal_erik 11y agoThe only way to keep old code working would be to add generics but continue having an awful standard library that never uses them.
- anonymoushn 11y agoWhat old code would break when adding generics?
- 11y ago
- PopsiclePete 11y agoYep! Confirmed in Go 1.6. Also - algebraic data types, monads, operator overloading, actors, STM, multiple inheritance, exceptions, LINQ, full opt-in dynamic typing, optional GC! Anything you want! All language features, ever conceived, will be crammed into Go, starting with the next release!
- artursapek 11y agoNo shit! I'm buying my ticket to Gophercon immediately
- bketelsen 11y agoI just scanned registrations and don't see you there....
- Dewie3 11y agoPity about the algebraic data types + multiple inheritance. That probably won't play nice.
- Rapzid 11y agoTotally. Even the guy who first introduced data types + multiple inheritance has come out to say that it's the worst thing he has ever done in the whole history of everything from always.
- aikah 11y ago> Any updates regarding generics and error handling? Don't hold your breath. it's unlikely the go team will add generics to the language, that's obviously a political issue not a technical one. Same for error handling. At least 2 people on the record, including Rob Pike said no new feature will be added to the language. It doesn't mean you should stop asking for them, but it ultimately means that people wanting generics and other features in Go should consider a fork Forks are ALWAYS healthy, the nodejs/iojs story is yet another proof of it. The thing people wanted (iojs) has won over the original project, which forced nodejs merge iojs back. Like many I personally think Go isn't striking the right balance between minimalism and features. People who are against generics are in favor of trading compile time type checking(which is always safe) for run time type assertions(which can fail). But they refuse to acknowledge that fact. That's what make their argument against generics wrong and will ultimately damage any potential growth for the language.They are basically working against their own interests.
- rsc 11y agoI'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 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.html 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/TypeParameters.html#FAQ106 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-russ-cox-and-sameer-ajmani/ 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.