16 ms·
Expectations for generics in Go 1.18
- dgunay 5y agoVery reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
- benhoyt 5y agoIsn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something that looked like a function.
- javier2 5y agoIt is both, because multiple return values break function chaining.
- dgunay 5y agoRight, I suppose I forgot that a big reason `Result` works well in Rust is the `?` operator. At the very least, I'll appreciate having some more sugar over loops that are essentially just map/filter.
- tialaramex 5y agoThe ? operator wasn't in Rust 1.0 Before Rust 1.12, Rust has a macro, named try! which does a similar thing to its argument although the built-in operator has some fancier features.
- topspin 5y ago"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?" It's both. Adding only concise flow control, such as with the ? operator, works poorly if all you can return is multiple non-generic values; various common permutations get awkward in that case. And as you point out Result<> doesn't achieve much without the concise operators. Rust has very successfully shown the benefit of the combination.
- ipmonkey 5y agoEarly return is definitely a part of the problem. One thing you could do with generics is create option/result wrappers that would work with any code and hack together a try/early return solution using panic/recover, but you'd offend the Go community, and at that point you might as well just use Rust.
- tptacek 5y agoI wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
- rustnote 5y agoI like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there's a language that has such a strong vision, but dealing in absolutes has drawbacks, a little sytactic sugar would make error handling a lot nicer.
- fourseventy 5y agoFor what it's worth I really like how go handles errors.
- camkego 5y agoWas the try() proposal for Go error handling? I'm really curious what happened to the proposals for shorter Go error handling, rather than if err!=nil {...}
- mseepgood 5y ago> Was the try() proposal for Go error handling? Yes, it was the second proposal by the Go team for shorter error handling: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-... > I'm really curious what happened to the proposals for shorter Go error handling The community didn't like it and it was declined: https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203...
- infogulch 5y agoGenerics took several iterations from the Go team to finally land on the current (pretty good, imo) design. I might expect error handling to also require multiple tries before it sticks. And we should probably wait for the dust to settle on generics a bit before proposing another design for error handling.
- mohanmcgeek 5y ago> How are you thinking of solving this with generics? People can now create Try or Option monads instead of returning the error. This was the one of the reasons anti generics people were anti generics
- mseepgood 5y agoBut that will make error handling more verbose.
- stouset 5y agoSpeaking as a user of languages that have exactly this, it can’t possibly be any worse than the situation in Go right now.
- mseepgood 5y agoOther languages have an additional zoo of language syntax besides generics to make monadic error handling bearable, which Go doesn't have.
- EdwardDiego 5y agoWill it? I can't see it myself, but happy to educate myself.
- mohanmcgeek 5y agoIt'll make it unmanageable by hiding complexity. But more verbose? I'm not so sure.
- mseepgood 5y agoPassing a single anonymous function is already more characters to type than if err != nil {}.
- johnisgood 5y agoI want the "if err != nil" back!
- mseepgood 5y agoI don't see how it changes error handling. To implement a generic error handling function you would need a non-local return statement (panicing is not error handling). And a generic monadic Result type would make error handling more verbose due to its reliance on closures for subsequent actions.
- EdwardDiego 5y agoThis is why Java went with type erasure...
- vptr 5y ago> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts. I have a feeling this won't happen.
- oppositelock 5y agoYou're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18. My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, which is difficult, because I really like the feature.
- gonzo41 5y agoWell for the users, they should be upgrading anyway. I can't see a situation where someone would mirror your library in and not also have brought, or be bringing in a non breaking language change in the new golang. The only change management advice I could give, that you'll probably know, would be to roll a month slower than golang.
- ithkuil 5y agoUpgrading to the latest release of the Go toolchains is generally a painless experience; the Go team has a good track record of enforcing backward compatibility. Hopefully this means that you can assume other users will be able to use code targeting new features of go 1.18 in pretty much the same time window it takes for other releases to supplant old ones, and make this feature not unlike previous (minor) language features that nevertheless would break users who cling to too old toolchains. I hope that the publicity caused by generics doesn't taint this release causing people to unnecessary procrastinate a toolchains update they would have otherwise done if it wasn't for generics.
- 5y ago
- jimbob45 5y agoDoes anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502 https://github.com/nim-lang/Nim/issues/3502
- mseepgood 5y ago> Does anyone know the impetus for using [] in generics? Yes: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des...
- blondin 5y agois it really the case that parsers can't tell the greater than sign in "a, b = w < x, y > (z)" without type information? or is it simply difficult to parse for some parsers?
- nemothekid 5y agoThe doc says it's actually impossible, and I'm inclined to believe so. Rust has a similar problem in their case they adopted the "turbo fish" operator, where the generic function call would take the following form: let (a,b) = w::<x,y>(z);
- mseepgood 5y agoCan you as a human? If you can't do it a parser can't do it either.
- arp242 5y agoIt's a problem all languages with <..> need to solve one way or the other; see e.g. https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-generics.html https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-gener... So for C# it's resolved "by examining the token after the closing >: If it is one of (, ), ], :, ;, ,, ., ?, == or !=, the expression is parsed as a generic method call." I assume this works reasonably well; however, it's not hard to see how this might be a problem in some cases where the parser gets it wrong.
- oefrha 5y agoRelated discussion from 10 days ago: go: don't change the libraries in 1.18 https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918 https://news.ycombinator.com/item?id=28895440 https://news.ycombinator.com/item?id=28895440
- VHRanger 5y agoHow are they implemented? Compile time? With template expansion like D and C++?
- mseepgood 5y agoGC Shape Stenciling, a hybrid of stenciling and dictionaries: https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
- rustnote 5y agoSo there's a runtime cost for using generics?
- wwarner 5y agoYes, the same cost as calling a method through an interface. IIUC, the concrete implementation can change.
- mseepgood 5y agoNo, it does not have the same cost as calling a method through an interface.
- Kranar 5y agoThe linked article is a proposal but at least when I tried Go a couple of weeks ago, it did not use that approach and to the best of my knowledge that proposal has not yet been implemented. Instead as of now Go uses the straight forward approach of generating one implementation for every instantiation just like C++ compilers do. The upside is there is no runtime cost to using generics, the downside is there is significant compile time and link time cost to generics.
- arc619 5y ago> the downside is there is significant compile time and link time cost to generics. Are we talking statistically significant or productivity significant compile time cost? Go has a fairly fast compiler, it would be a shame if generics made that a less stand-out feature.
- SheinhardtWigCo 5y agoIf you want to get a head start, gotip makes it easy to build and run go from the development tree: https://pkg.go.dev/golang.org/dl/gotip https://pkg.go.dev/golang.org/dl/gotip
- Benjammer 5y agoThank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
- topspin 5y agoOn the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
- deleted 5y ago[deleted]
- glouwbug 5y agoCanadians now roll with the term Indigenous instead of Aboriginal
- spenczar5 5y agoThat may be, but in this case it is a precise technical term, referring to a particular block of Unicode: https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_Syllabics_(Unicode_block) https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_... Maybe the Unicode Consortium should change it, but for now, Canadian Aboriginal is the correct term.
- uuddlrlr 5y agoColloquially in the north "native" is ubiquitous.
- andai 5y agoFor now...
- 5y ago
- benreesman 5y agoIs the garbage collector still an undergraduate project, or did Pike hire Cliff Click while I wasn’t looking?
- samtheprogram 5y agoFrom the outside, it seems like adding generics to Go seems similarly controversial and slow as the Python jump to version 3 — although Go generics haven’t even landed yet. Generics have the potential to impact a decent amount of the standard library. Although I’m not surprised that they are not doing a major version bump given the isolation of the feature at this stage, it will be interesting to observe its uptake in the community and whether fragmentation occurs over what is supported and what isn’t given their recommendation of isolating generics-related code in third party libraries.
- benhoyt 5y agoI don't think it's anything like the Python jump from 2 to 3. That changed the behavior of a lot of code (unicode vs bytes, various syntax changes, import changes, etc), and there was no way to automatically upgrade a codebase (2to3 didn't really work). With the addition of generics to Go, they've been careful to ensure it's fully backwards compatible, so all existing code will still work as is. Major version bumps are for incompatible changes (like Python 2.x to 3.x). What they're recommending with isolating generic code in existing libraries is so users of older versions of Go (1.17 and prior) can still use those libraries, just not any new functions/types the libraries have added that use generics, and hence require Go 1.18.
- jez 5y agoYep, and in particular, the version 1 moniker in Go has a precise meaning that the Go team committed to at 1.0: https://golang.org/doc/go1compat https://golang.org/doc/go1compat The fact that they can release generics and NOT bump to 2.0 is a triumph of the language designers and implementers, a testament to how much effort has been put into keeping this commitment.
- hota_mazi 5y ago> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.
- fulafel 5y agoTrivia: parametric polymorphism (aka generics) was first done in ML, 46 years ago. WP cites this reference: Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975) (And of coures we've been able to write generic code in dynamic languages for a long time as this is a static typing concept)
- silasdavis 5y agoGo is Special and not comparable to these lesser languages.
- skybrian 5y agoGiven that every language is different, this is basically reasoning by analogy. Sometimes analogies are useful for explaining things, but they're not a reliable way of determining what will definitely work. Reasoning by analogy in a sneering way doesn't make it work better.
- adwn 5y agoProgramming languages differ, yes, but not so much that they face completely different design decisions. Also, it's not "reasoning by analogy", it's learning from others. In fact, why stop at generics? Why not go back and question structured programming? Or strong typing? Because structured programming and strong typing has proven to be extremely useful. Same as generics in statically typed languages.
- skybrian 5y ago
- awestroke 5y agoAnd so Go is one step closer to being a real programming language in many people's eyes.
- nprateem 5y agoFor the love of God please let throwable and catchable exceptions be next
- konart 5y agoHopefully not and never.
- kubb 5y agoThey already have it with panic and recover. They just don't recommend using it for error handling.
- chairmanwow1 5y agoEven if this behavior is similar to how Java exceptions work, I love the way go packages are written. Explicit error handling can be tedious, but I’m never confused about what some code will do. Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from. Would be nice to have this abstracted away with tooling though. I would imagine go generate could be used to great effect in this arena.
- kubb 5y agoI'm just stating a fact, it's slightly unnecessary to reply with your declaration of love for Go. I prefer returning errors as a part of the function result myself, as you would in any decent language encouraging functional programming principles. If anything, it shows that including a feature in a language (exceptions) will not lead to people misusing it if that misuse is not encouraged.
- 5y ago
- rsj_hn 5y agoHad a long running bet that NCIS would be cancelled before Go got generics. Now it looks like I must eat my words.
- compsciphd 5y agoeh, Mark Harmon left before Go got generics.
- rsj_hn 5y agohmm. So, a tie?
- pjmlp 5y agoFinally catching up with modern times.
- geodel 5y agoI have heard even Java is going to catch up with modern times with Valhalla and maybe even futuristic later on, where a directory tree of source files can be compiled without weird twisting of java command line.
- pjmlp 5y agoNot paying attention to the AOT compilers available since 2000, or optimizations available on IBM J9? I guess it is a thing, after all Go folks tend to ignore the experience from other programming communities.
- kubb 5y agoI'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.
- sudhirj 5y agoSigh. Go without generics was useful. We built useful things with it. Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier. The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever knowing about or using generics. Generics coming into a 1.x release also means that any code written under 1.x is expected to continue working perfectly, generics or not. The process has made sure no damage will be done, and we now have a new toolkit to make solving some problems easier. I don't think anyone is trying to gaslight anyone by using generics.
- kubb 5y agoThat's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created". And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing to keep in mind when opinions are being pushed on HN.
- y4mi 5y agoOften the people that expressed that opinion are different people then for example the person you responded to here. Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions. Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... change their opinion? Or at least has to be continuously told that they're dumb because they held an opinion that turned out to be incorrect? We're all people and make mistakes/have incorrect assumptions about topics, why not just accept that and move on? You might want to refocus on what kind of person you want to be, because both of your comments come off as very hostile