8 ms·
A concise guide to the latest Go generics draft design
- maxmcd 6y agoWhat kind of new libraries are we going to get with this change? Seems like we'll see a proliferation of new data structure libs now that they can be constructed without interface{}. What else?
- jerf 6y agoLibraries that assemble channel structures, and libraries that may not provide that functionality but depend on it internally, i.e., libraries that can set up entire structures of goroutines that use channels under the hood. (Probably another burst of "worker pool" libraries will pop up before once again the community points out that native Go essentially provides worker pools with a natural use of existing constructions already.) While this is a subset of "new data structures", I'm really looking forward to generic immutable structures that can be read by many goroutines but have some coherent update story. I've got several places in my code where I have a structure I want to update infrequently and have read access in a lot of places, where I'm reading it enough that a traditional read/write lock is a real problem. I've got some stuff hacked together but what I have can't be shared as a library, and I shouldn't anyhow, because a real library ought to be stronger and better. (I recognize that Go doesn't have immutable data types, but I was programming in Python for many years before Go and have made my peace with "Just don't do that.") Libraries that operate on maps and slices in a type-agnostic manner. Probably some numeric libraries with nicer types than you can get now, though I still think Go will be a bad choice for highly numeric code even post-generics. Several hundred map/filter/reduce libraries that nobody will use for very long. Data structures are the one I'm really looking forward to, though. Network servers, nominally Go's wheelhouse, is one of those places that we tend to like some obscure data structure choices because of the performance needs. It has been a frustrating hole in the language for a while.
- maxmcd 6y agoThanks, this was super informative
- obilgic 6y agoBack in the day, if you mentioned generics on any Go post on HN, you would be downvoted to the hell, interesting how everything comes full circle (unfortunately a bit late).
- MrBuddyCasino 6y agoSame with the hand washing/wearing masks inversion regarding COVID19 - people made fun of you two months back for preaching the obvious, and now nobody will even go as far as admit they were wrong, let alone apologise. Human nature. ️
- Bjartr 6y agoIIRC, that's because it got mentioned on EVERY Go post. People got tired of "Go should have generics!" and the ensuing arguments dominating every discussion about Go.
- obilgic 6y agoand still it took how many years?
- _ph_ 6y agoComments like yours are exactly the reason, the mentioning of generics lead to quick downvotes. Not aknowledging the reasons for not having generics right off the start, which have been clearly communicated by the Go maintainers. Comments, which don't add any substance to the discussion (usually they were even made out of context) and are pure nagging.
- jrockway 6y agoGo is on its way, like everything, through the Hype Cycle. It started at the Peak of Inflated Expectations ("Java will disappear overnight, and I sure hate Oracle and that one Java program I heard about 15 years ago"), and at that stage, any article that mentioned Go would get upvoted. Then came the Trough of Disillusionment. There were probably enough HN readers that had used it to realize that it wasn't the solution to every problem -- bad Go written by bad programmers was bad! I was promised that was impossible! It became the subject of flamewars both from bad experience and to push back against the visibility people didn't think it deserved. (Lots of reasons for this -- they wanted to write something in Go and nobody let them, Go came from Google which HN hates, etc.) The pushback here that really got traction was "Large company that I would normally hate because they sell ads has rewritten some small Go microservice in a new cool programming language." HN was willing to ignore its hatred for large companies, ads, and microservices as long as the article was shitting on Go. You gotta null out the Peak of Inflated Expectations somehow. Now we have entered the Slope of Enlightenment. Go has most of what it needs to be successful, and is objectively successful. So now it can be tweaked and refined -- time spent in the trenches making TLS or HTTP/2 or GC better has mostly made those things better, and it's on to the next things -- generics being the big one. You should watch the Hype Cycle very carefully with Rust. Rust is no doubt on its way to a Plateau of Productivity, but right now we're at the point where "My company only uses Rust!" or "I rewrote my foobarlang app in Rust!" will get you to the first page... but "Wow, my CI system spent 387 CPU days building my Hello World app last week!" is also starting to show up (on its way to the Trough of Disillusionment). I hate when things fall into rigid categories because it seems overly simplistic, but the Hype Cycle is spot on. Look for it and you'll see it everywhere.
- YoyoyoPCP 6y agoWish comparable supported all of the compare operators. Otherwise, this looks like a nice design by the Go team!
- sszz 6y agoThanks for this—easier to digest than other posts I’ve seen. The ability to restrict interfaces to specific types is pretty cool (unique?) but otherwise seems like generics as usual, but with a distinct Go flavor. Looking forward to using this and cleaning up some boilerplate!
- maybeOneDay 6y agoUnless I'm missing something I can't see any constraining ability that isn't possible in C#[0], for example? [0] https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/constraints-on-type-parameters https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
- scns 6y agoMaybe you are missing that this is not possible in Go yet?
- throwaway894345 6y agoI do wish people would resist the reflex to overtly digress onto their own favorite programming language in any given programming HN thread. I'm not talking about insightfully comparing two languages; I'm talking about going completely off-topic because you want to talk about your own favorite language.
- maybeOneDay 6y agoIf this is in reference to my bringing up of C# - I did so in order to talk about whether or not Go has generic constraints which are unique (which would be awesome!). I used C# as an example of a language that has constraints that are the same as/as powerful as those in this Go proposal so as not to be making an unsubstantiated claim.
- roblabla 6y agoOP specifically said the constraining mechanism was unique, hence why GP (and myself) are curious about what makes it more interesting/powerful than what exists in other languages like C#.
- cutler 6y agoSimplicity goes out the window. Oh well it was nice while it lasted.
- gmassman 6y agoLooks a lot simpler than contracts... I'm much happier with the aesthetics of using interfaces for generic constraints. Looks a lot simpler to use. Besides, it's completely compatible with existing code, only a minor update will be required. Seems to me to be one of those features people will ignore if they don't want but love in the instances where there would otherwise be lots of boilerplate and/or generated code.
- throwaway894345 6y agoI didn't pay much attention to the contracts proposal; is this just simpler because dynamic dispatch is vaguely similar to static dispatch, so it uses one syntax construct (interfaces) to denote both? I'm not opposed to this, but these aren't "interfaces" even though they use a similar syntax, notably the "constraining to a set of types" is supported for constraints and not interfaces. The thing I worry about the most is that Go without generics works very well for 95-99% of code. The code is very clear and not overly abstract. The remaining 1-5% of code is hard to write in an efficient, type safe, and DRY way, but I don't see how we can have generics and clear, appropriately-abstract code. I strongly suspect this will change the quality of the ecosystem for the worse. I don't think people consider this tradeoff very often.
- jasonwatkinspdx 6y ago> I don't think people consider this tradeoff very often. Every single time generics in go is discussed, a sizeable fraction of the comments are FUD about go inevitably turning into Boost. People consider the tradeoffs often, but in a superficial and dogmatic way based on language tribalism rather than actually looking at the proposal in detail and actually considering the tradeoffs.
- 6y ago
- troughway 6y agoI think the proliferation and cultural dominance of Rust finally put a zap on these people’s heads. Doesn’t matter though. Rob Pike’s smug tone and hubris when it comes to why Go does and does not have certain things is not something easily forgotten. Treating your audience like idiots is one way to grow mindshare among technical people. There is something to be said for longing for some vague idea or notion of how things ought to work, and philosophies oriented around Plan 9 and BeOS capture this longing very well. But people who actually get shit done - the “programmers” for whom “system programming” languages are supposedly designed for, may not share this sense of nostalgia. I suspect Rust will be a very costly lesson for them indeed.
- sk0g 6y agoDo they even service the same domains though? For me, Go is a faster, more explicit Python. In some domains, it is even more batteries-included, especially where I use it - backend development. It has a great balance of ease of development, deployment, and performance. Sure, it was billed as a systems language at first, and it saw some traction there (Kubernetes, Docker, etc), but IMO, it sits halfway between Python and C, and it's a language I'm quite happy with for the most part.
- skrtskrt 6y agoseriously, for most of us it's just faster statically typed Python and it rocks at that.
- dalu 6y agoit doesn't matter what we say, Go is owned by Google and what they decide is the Alpha&Omega, everything else will be silenced, banned, ridiculed, ignored, closed, deleted. And in my case, my Adsense sites suddenly having "policy violations" after 14 years of existence and pages being removed or deranked from the Google index. Be careful what you say because those powertripping ivory tower elitists will destroy your business if you have any earnings from a partnership with one of their products. I'm willing to be if I had GCE containers they would also have magical errors appearing just in the moment when I DARED suggest they revert a font and they change their "brand" because it's soulless and has nothing to do anymore with the spirit that made Go popular, simplicity and readable code. Oh and of course one corrupt organization washes the other's hands. Your github account will get flagged without notice or reason given and inquiries will remain unanswered by Github. Corrupt bastards is what the Go developers are. Go is not your (as in mine, ours) language. It's a language owned by a corporation that turned evil, that spies on all of us and hands out data to governments. An evil corporation that cooperates with totalitarian regimes, because their mindset is similar anyway, so what's the deal, right? All just business as usual. Screw the public, we own the place. .|.. Google and the Go developers
- stickupkid 6y agoI feel the lack of additional type arguments on methods will be considered a mistake in the longer term. Although the way it's designed it can be added in additional revisions but considering it's taken rather a long time to get here, I don't hold much hope for it landing for some time. Attempting to define a generic Map function turns out to be somewhat troublesome[1]. This would be really painless if you had type arguments, instead, we have to define an interface to allow peeping into the type and creating a type from a zero value. Don't get me wrong, I do applaud the efforts for better type system, it's just a weakness in the proposal. 1. https://go2goplay.golang.org/p/P7CVwOW9wig https://go2goplay.golang.org/p/P7CVwOW9wig (note this panics currently)
- deleted 6y ago[deleted]
- tarkin2 6y agoI’m ignorant to golang’s generics saga, but I’m painfully familiar with Java’s (to the point where I wasn’t overly sad when golang didn’t have them). Can anyone explain what golang is doing better?
- hu3 6y agoThey're different languages with different goals. Such comparison wouldn't be constructive nor conclusive.
- cle 6y agoGo is designing generics around the language tenets, which are quite different from Java's. In themselves, generics aren't particularly interesting...it gets interesting when you start considering the tradeoffs you need to make in order to align them with the tenets of your language, runtime, and ecosystem. I wouldn't say Go is doing generics "better", they are doing them "differently" to align with the goals of the language. (Personally, I'm not looking forward to generics in Go, I enjoy the simplicity of not having them and haven't encountered situations where they'd make a huge difference.)
- atombender 6y agoGood introduction. I have to agree with other commenters that the syntax leaves something to be desired. A lot of parentheses competing for attention. Perhaps we could take a leaf from the Modula-3 book — Go was influenced by Modula-2, which didn't have generics — and be more explicit in declarations. I feel this would be more in the tradition of Go. For example, instead of func Max(type T Comparable)(a, b T) T { if a > b { return a } return b } This could instead be enveloped by a "generic" declaration like so: generic T Comparable func Max(a, b T) T { if a > b { return a } return b }
- loopz 6y agoWhile skimming, I find the article-examples largely unreadable compared to idiomatic Go. You'd almost require generic-aware syntax highlighting in order to grok complex syntax, which breaks normal readability. Experimenting with wrapping as you suggest, seems a good way to see if that separates concerns in syntax enough to make generics "fun again". Programmed for long time in C++ w/templates . Any and everything that avoids the hells of those syntax and compiler error/messages, could even be called innovative if hitting the right spots. I see generics as convenience, but only if the costs doesn't accumulate over time * complexity. Generics need to be something natural, not bolted onto a language, or sneaked in. Unlike precompiler defines, and templates to some degree. To that end, maybe it deserves its own nomenclature, form and space, to properly distinguish those special cases from more concrete cases of syntax. Just like we distinguish looping with "for".
- atombender 6y agoAgreed. To keep Go simple and keep it from descending into the kind of extreme generics that Rust practices (nothing wrong with it, but it seems antithetical to Go's simplicity), the idea behind my syntax suggestion is to think about monomorphization as an explicit concept. You're basically telling the compiler to generate new versions of the same function, or struct, or whatever. The mental challenge with just adding type parameters is that you're thinking of the type as generic, which creates "what colour is my code" distinctions; either types are generic or they're not. I had another syntax in mind that would reuse the "for" keyword: for type T: func Max(a, b T) T { ... } Both syntaxes work fine for other declarations; structs and methods, for example: for type T: type Atomic struct { v T } for type T: func (a *Atomic) Get() T { ... } Of course, you still need some syntax to specify types in expressions, but that's also solvable.