21 ms·

Generics enabled by default in Go tip

264 points by dcu 5y ago

3np 5y ago
Wow, it's happening! For others completely out of the loop on that there was even an accepted proposal that is now being implemented: https://go.dev/blog/generics-proposal https://go.dev/blog/generics-proposal
- dang 5y ago
  Some related past threads: Golang generics proposal has been accepted - https://news.ycombinator.com/item?id=26093778 https://news.ycombinator.com/item?id=26093778 - Feb 2021 (168 comments) Go generics proposal moves to “likely accept” - https://news.ycombinator.com/item?id=26018649 https://news.ycombinator.com/item?id=26018649 - Feb 2021 (92 comments) A Proposal for Adding Generics to Go - https://news.ycombinator.com/item?id=25750582 https://news.ycombinator.com/item?id=25750582 - Jan 2021 (270 comments) The Next Step for Generics - https://news.ycombinator.com/item?id=23543131 https://news.ycombinator.com/item?id=23543131 - June 2020 (664 comments) Generics in Go with Ian Lance Taylor (2019) - https://news.ycombinator.com/item?id=22361089 https://news.ycombinator.com/item?id=22361089 - Feb 2020 (98 comments) Why Generics? - https://news.ycombinator.com/item?id=20576845 https://news.ycombinator.com/item?id=20576845 - July 2019 (254 comments) Go's updated generic proposal (Contracts) - https://news.ycombinator.com/item?id=20541079 https://news.ycombinator.com/item?id=20541079 - July 2019 (61 comments)
- omgitsabird 5y ago
  The full proposal is here: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
- d33 5y ago
  As an outsider planning to eventually learn Go, I have two questions: 1. what's "Go tip"? 2. does this allow us to approximate when it could make it to one of Go's stable releases? I guesstimate it's something that would land not sooner than within a year, right?
  - 4ad 5y ago
    The "tip" is the head of the development branch. The plan is to have them available as a preview feature in the next stable release, which is scheduled in about 6 months time.
i_have_to_speak 5y ago
It is available in Go 1.17 with a flag, use: go run -gcflags=-G=3 foo.go
- uluyol 5y ago
  The support in Go 1.17 is very incomplete. A lot of work has been done in a branch (since merged) after the 1.17 freeze.
peter_l_downs 5y ago
Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX https://go2goplay.golang.org/p/krvTH1_7lwX
- topspin 5y ago
  Result[T] plus a ? operator to provide concision would be a huge win for Go.
- nynx 5y ago
  Result isn’t an enumeration of sorts?
  - infogulch 5y ago
    No, Go doesn't have discriminated/tagged unions or valued-enumerations or whatever you want to call them, but generics let you hack them in without much trouble. Personally I'd take ADTs over generics any day, but it's not a dichotomy maybe we'll still get them some day. https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412
- ramchip 5y ago
  > Viewing and/or sharing code snippets is not available in your country for legal reasons. This message might also appear if your country is misdetected. If you believe this is an error, please file an issue. Wow, interesting. I'm in Japan.
  - Cloudef 5y ago
    Works for me (also japan)
  - Santosh83 5y ago
    Shame as a species we can't even share information (literally bits on the wire) globally, even if tangible goods and movements are circumscribed by political borders.
bitwize 5y ago
Now if they can shitcan the GC, Go might come within spitting distance of being competitive with Rust.
silisili 5y ago
Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.
- _wldu 5y ago
  I agree about placating. Go is fine as it is. I don't need or want generics, but the addition of generics won't stop me from using Go.
  - silisili 5y ago
    It might me, in time. As mentioned, my main interest in Go is in how easily I can read others code. This kinda ruins that, even if I never use it.
    - tengbretson 5y ago
      Learning something is also an option.
      - silisili 5y ago
        Thank you.
      - jshen 5y ago
        Learning things outside of complex computer science topics often adds more value to the world. The ability to write useful programs without dedicating ones life to esoteric comp sci topics is a net positive for the world.
        rustc 5y ago
        Are generics really considered as "esoteric comp sci topics"?
Taek 5y ago
Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.
- 5e92cb50239222b 5y ago
  Even I know (not really being a heavy C++ user) that C++ doesn't have generics, it has templates, which is a much more powerful concept that's often overused.
  - masklinn 5y ago
    > Even I know (not really being a heavy C++ user) that C++ doesn't have generics, it has templates So… you know wrong? Templates are a form of generics. What templates are not is an instance of parametric polymorphism.
- papaf 5y ago
  Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. The culture might help. I think generics in Java are not overused -- partly because they are not so powerful and partly because Java, similar to Go, did not have generics for a long time.
  - randomdata 5y ago
    C++ also went a long time without generics, and even when support started to appear it was a separate code generation step, requiring even more time before we saw first-class compiler support. Powerful, though.
- jrockway 5y ago
  The key to readability is programming with readability in mind. Sure, languages play some part in that, but 90% of it is the programmer. Go is simple right now, and generics do complicate it, but even with the simplicity that Go has, people already make a giant mess of it. As soon as you get any advanced feature, people will abuse it -- colossal generic functions that take 5 interface{} arguments (but only ever operate on strings), one-off interfaces that have 35 methods, calling out to cgo just because they can, and giant tangles of goroutines, mutexes, semaphores, and sync.Pools all mixed together into one big ball of sadness. But, while everyone has the ability to create such a disaster area, some opt out and use the tool correctly -- making the advanced language features an asset instead of a liability. I don't think generics will change this; when used sparingly and at the right time for the right reason, it will make the code easier to read. I did a quick look through all my open source projects to see where I have accepted or returned an interface{} in my own APIs, which is a strong signal that I'm looking for generics, or am using a library that wants generics. One case is interacting with Kubernetes. I have two applications where I set up a reflector like `cache.NewReflector(lw, &v1.Node{}, store, resync)`, to keep a cache up to date; the implementation of "store" takes interface{} for all the arguments (Add, Delete, etc.), even though it only ever operates on a v1.Node. Generics will let me ensure at compile time that I only have to worry about v1.Node objects. Right now, that's handled with runtime assertions in the reflector itself, and in every implementation of the cache.Store. Generics clean this up. Another case that comes up is processing random JSON objects from the Internet with no defined schema. Those end up as map[string]interface{}, and that won't change. The last case is unmarshaling functions. I see some (in a JWT validation library) that are of the form `func Unmarshal(string) interface{}`. I don't really know what's going on there, and I don't know if generics will help. (Similarly, for the common case of unmarshaling JSON, I'm not sure generics can improve the `err := json.Unmarshal(bytes, &result)` API. I will have to look into it. That's about it.
tedunangst 5y ago
Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.
- silisili 5y ago
  Or good case study of squeaky wheels. I never wanted generics. I never thought to spam the development lists about how much I liked how things were going.
  - bigdubs 5y ago
    a couple high profile projects (k8s) needed generics, there are limited use cases outlined in the planning docs that detail the holes in the language they're filling, it wasn't just squeaky wheels.
    - silisili 5y ago
      Shame how k8s was a failure without generics. Think what could have been.
      - Zababa 5y ago
        The thing is, Google is paying most of the development costs for Go and Google controls Go too. It makes sense to adapt the language to their needs. They already do stuff like creating new network protocols because it will reduce their costs.
        loopz 5y ago
        Google have alternatives to k8s already. So it's more about making a market.
        Zababa 5y ago
        I've heard multiple times that Google Cloud has the best support for k8s, and that people moved to it because of that. Is that what you meant by making a market?
durbatuluk 5y ago
If you want all features of language X (I doubt we will stop at generics) use language X. Stop trying to make all languages the same. I work with programmers from OO background (java) and they can't even grasp the utility of functions as value or closures. Every damn "service" has an interface/generated mock and anemic model. They're desperate waiting for generics for go to "complete". I fear the influx of OO programmers.
- chana_masala 5y ago
  OO !== Generics, at all
  - durbatuluk 5y ago
    I didn't say they're the same. I'm saying people coming from OO complain all the time of lack of generics, inheritance (besides composition) etc. I teach basic go at my job to help people wanting to migrate, they start the go journey thinking go will do "less" because we don't have all features as their main language. Which reminds me of this phrase: > 'You cannot reduce the complexity of your problem by increasing the complexity of your language.'
brundolf 5y ago
I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to. One thing I'm curious about: user-defined generics I can see going without, but the core language and standard library surely need to have them. How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code?
- skybrian 5y ago
  There are the usual operators and special functions like append(), which is implemented in the compiler and works on arbitrary slices. Not many of them, though. They are defined in the builtin pseudo-package: https://pkg.go.dev/builtin https://pkg.go.dev/builtin
- takeda 5y ago
  Java didn't have generics until version 5. They were added 8 years later.
  - masklinn 5y ago
    c# was also released without generics, they wanted it out the door and the generics were not ready. They landed in 2.0.
  - int_19h 5y ago
    Java didn't have user-defined generics, but it did have parametrized builtin types: arrays. Same thing for C#.
- masklinn 5y ago
  > How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code? They’re special-cased in the compiler, with bespoke implementations.
awinter-py 5y ago
those aren't generics they're from the canadian aboriginal syllabic block
- erik_seaberg 5y ago
  For anyone who doesn’t get it, https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_... was a pretty funny workaround.
ammmir 5y ago
the generics mafia has ruined rust and looks like go is next.
- anothernewdude 5y ago
  I shudder to think what Rust would look like without generics.
tannhaeuser 5y ago
Not entirely getting the hate/hype towards generics. What about run-time reflection and annotations, arguably an addition with more drastic consequences, and all things considered, not for the better IMO. Has anyone an opinion on using GraalVM/Java vs Golang?
tapirl 5y ago
Go needs custom generics for sure. But it is really a hurry-up to support custom generics for Go in version 1.18. Many problems have not been resolved yet. * should the builtin generics syntax be compatible with the new custom syntax * how many problems will be solved by the custom generics and how much complexities will be added. Is it a good balance?
- int_19h 5y ago
  The second question has been extensively answered by numerous mainstream languages adopting generics in the past, oh, 30 years or so?
jagger27 5y ago
Pretext: I love Go and write most of my day job code in it. To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. Little things like sorting will use generics pretty much transparently. All of the strongly typed code you write today that receives and returns concrete types will be just as valid tomorrow as it is today. Interfaces keep the same semantics and are a core part of how generics work. I think it’s important to remember that the people who design this language like it for the same reasons you do.
- masklinn 5y ago
  > To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. In fairness: just because that's true doesn't mean the libraries they like or need won't be migrating to generic facilities one way or an other, so they may be forced to the choice of interacting with generics or needing to reimplement their wheels (though also in fairness that's also common in the go ecosystem). > I think it’s important to remember that the people who design this language like it for the same reasons you do. That's not necessarily true, the designers of the language are not necessarily designing it for their use or like. See: Rob Pike's well known quotes on the target population for Go.
evanmoran 5y ago
This is actually my first week using go (from years of C++/Swift/js/etc) and I’ve been very impressed with the module system and simplicity so far. I’d definitely encourage others to try it if they haven’t. As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. It will still be only in one place, where as in C++ you could have hundreds of functions with the same name across many libraries and you just have to hope your ide knows which to step into.
- masklinn 5y ago
  > As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. There are already a number of langages with generics and without overloading (or defaults). Haskell, ocaml, rust, …
  - 4ad 5y ago
    True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. In fact, once OCaml gets implicit modules, this won't be true anymore of OCaml either.
    - masklinn 5y ago
      > True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. That's no more overloading than Rust has through traits.
      - 4ad 5y ago
        It absolutely is, because class methods in Haskell are top level declarations. Not only this is not true in Rust, but it doesn't even matter as Rust doesn't have polymorphic values, only polymorphic types and functions. In Rust, unlike in Haskell or ML type inference stops at function boundary.
throwawaygo 5y ago
Sadly go is losing the spirit it was built with and alienating the experience that it needs to regain that spirit. This has been my top feedback every go survey is that it is being designed democratically where it needs to be led by experience.
- deleted 5y ago
  [deleted]
sascha_sl 5y ago
If you're really concerned about "clever developers", maybe you ought to ask for the removal of reflect and ast, because they've both been used to be way too clever about solving the same issue.
- valenterry 5y ago
  Correct. People will find a way to get rid of the verbosity and you either give them good tools to do it or you end up with a mess.
pjmlp 5y ago
Finally catching up modern times! Welcome to 1976.
shp0ngle 5y ago
Hey, instead of “return value, err”, we can now write it as generic Option! Kidding kidding, please don’t do it kids
valenterry 5y ago
Two thoughts: 1.) In a "simple language" (e.g. without generics) each line of code is easy to read/understand. But reading/understanding the whole program or application is difficult. In "not-simple languages" it's the other way around. 2.) An important criteria to judge the future of a language is how foresight the language authors have. I read that the go authors said in the past that they were not ready to add generics because they didn't know how to do so in a good way. True or not, retrospectively adding generics is not a great indicator for good language design to me. Even if the addition of generics is a net-positive thing, I expect that Go will go in the direction of C++, having a lot of accidental feature complexity in the language. I think it's better to do it like Lisp and keep a simple (but nonetheless flexible) core. Or do it like Haskell and design the language to elegantly allow as much abstraction as possible, moving carefully towards that goal. For these kind of languages, you better have people who have years long experience in exactly this: designing powerful programming languages. A developer can be the best in their own field, but they are doomed to fail when trying to build a future-proof, well designed programming language on their first attempt. (btw, not relating to the Go author's here) An example where this didn't work is Angular - from the first moment that I got in touch with it, I knew it was built by amateurs. It's only a framework, but the difference to a programming-language is minor in the case of these kind of all-encompassing frameworks. It is not surprising to me at all that the completely redesigned Angular later on.
smokey_circles 5y ago
Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity", stay away from it if you don't like the "verbosity". These are both valid points, but they're subjective. Pushing it as fact is dishonest and self-serving, as well as eventually detrimental.
- toolslive 5y ago
  Go has generics. They're just not (yet) available for you. So to some it feels like a Tantalus punishment.
  - ibraheemdev 5y ago
    If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up. [0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
    - masklinn 5y ago
      > If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. They're not generic (aka userland) generics, but they're still generics: parametric types, and functions able to work on them generically (you don't have a separate `append` function for every type you might put in a slice). > The generics proposal is being implemented from the ground up. Of course it is, the builtins are ad-hoc and half-assed. That doesn't mean they ain't a thing.
      - sagichmal 5y ago
mgraczyk 5y ago
Glad to see this finally happening. I've been writing a decent amount of Go lately and there are plenty of instances where this will make the code more readable.
ledneb 5y ago
What syntax did Go settle on, in the end?
- ledneb 5y ago
  Found it, I think https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
deleted 5y ago
[deleted]
_ph_ 5y ago
I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is, in a sense they are very comparable in my eyes). The interface concept is great for covering a lot of cases. That is, why so far, I have not missed generics much and was rather reluctant to the constant wishes to add them to the language. On the other side, there are cases, even if they are not very frequent, where generics do help a lot. Just the new slices package allone almost justifies the addition of generics. Furthermore, the proposal looks very much Go-like. As a consequence, I am quite looking forward to try them out and used responsibly[1], they can be a great addition to the Go universe. 1: I think the situation is somewhat similar to Lisp macros. Normally, a codebase rarely requires macros and readability is better, if you avoid creating too many macros. But occasionally there are situations, where using a macro tremendeously increases code quality. Both implementation and readability-wise. There macros should be used and it is great to have them available.
- zarzavat 5y ago
  I used to really hate Go's attitude to generics and type system features in general. I still do, but I appreciate that it's a matter of taste, and that different people have different tolerances for language complexity. People who like simplicity can use Go and people who like type systems can use Rust.
  - pharmakom 5y ago
    Weird to think of Rust as an alternative to Go imo. C# and Java are more similar to Go (mostly due to GC), but with generics etc
- papito 5y ago
  I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost every other ecosystem can be absent in Go. Want to run setup code before your test suite? You on your own, buddy. And, oh yeah, 2/3 of your code will be `if err` statements, because exceptions are passé. I learned it by seeking out good Go codebases, which are incredibly rare. Hashi's Terraform comes to mind. Infamously, the early Kubernetes code was a nightmare because it lifted and shifted Java idioms and that was at the company that invented the Language. Or at Uber, where they passed on Go's native goroutines and channels in favor of homegrown concurrency, for SOME reason: https://eng.uber.com/go-geofence-highest-query-per-second-service/ https://eng.uber.com/go-geofence-highest-query-per-second-se... All this to show that Go is not a simple language to do well, so let's dispense with that myth. It has its uses, but having done it, I would never recommend Go for a greenfield project in my place of work - there are very few rules that come with it, and it requires tons of coordination and discipline among a team. And if you have to work with 2 or 3 other people who have strong opinions on how to do things in Go, watch out.
yawaramin 5y ago
I'm not a Go user; I don't consider it serious as a programming language. True, it has great tooling. It seems perfectly designed for certain groups of devs to bang out lower-level tools and utilities, and they love it for being such a great fit. That said, I think some of them may have a point that Go shouldn't actually try to tack on generics now. Consider that generics are only one piece of the puzzle when it comes to programming language power and abstraction capability. There are also ADTs, abstract types, pattern matching, immutability, lack of null, expression-oriented syntax, etc. Go with generics would be only one step along that journey of abstraction power. It would help the set of people who desperately need it to solve their code repetition and type-casting issues. But it would solve these problems just to clear the way for them to reach the next set of problems on the journey of abstraction.
amw-zero 5y ago
Generics introduce complexity. That’s pretty undeniable. There are also cases where generics provide much better solutions to problems. That is also undeniable. As someone who’s working in a Go codebase at work, I’m happy they added generics, especially in the way they did. It’s a pretty minimal subset of generic functionality. I will apply it in certain cases, mostly to reusable code. I think it’s a big win overall though, without introducing too much complexity to the language.

264 points by dcu 5y ago

3np 5y ago

Wow, it's happening! For others completely out of the loop on that there was even an accepted proposal that is now being implemented: https://go.dev/blog/generics-proposal https://go.dev/blog/generics-proposal

dang 5y ago
Some related past threads: Golang generics proposal has been accepted - https://news.ycombinator.com/item?id=26093778 https://news.ycombinator.com/item?id=26093778 - Feb 2021 (168 comments) Go generics proposal moves to “likely accept” - https://news.ycombinator.com/item?id=26018649 https://news.ycombinator.com/item?id=26018649 - Feb 2021 (92 comments) A Proposal for Adding Generics to Go - https://news.ycombinator.com/item?id=25750582 https://news.ycombinator.com/item?id=25750582 - Jan 2021 (270 comments) The Next Step for Generics - https://news.ycombinator.com/item?id=23543131 https://news.ycombinator.com/item?id=23543131 - June 2020 (664 comments) Generics in Go with Ian Lance Taylor (2019) - https://news.ycombinator.com/item?id=22361089 https://news.ycombinator.com/item?id=22361089 - Feb 2020 (98 comments) Why Generics? - https://news.ycombinator.com/item?id=20576845 https://news.ycombinator.com/item?id=20576845 - July 2019 (254 comments) Go's updated generic proposal (Contracts) - https://news.ycombinator.com/item?id=20541079 https://news.ycombinator.com/item?id=20541079 - July 2019 (61 comments)
omgitsabird 5y ago
The full proposal is here: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
d33 5y ago
As an outsider planning to eventually learn Go, I have two questions: 1. what's "Go tip"? 2. does this allow us to approximate when it could make it to one of Go's stable releases? I guesstimate it's something that would land not sooner than within a year, right?
- 4ad 5y ago
  The "tip" is the head of the development branch. The plan is to have them available as a preview feature in the next stable release, which is scheduled in about 6 months time.

i_have_to_speak 5y ago

It is available in Go 1.17 with a flag, use: go run -gcflags=-G=3 foo.go

uluyol 5y ago
The support in Go 1.17 is very incomplete. A lot of work has been done in a branch (since merged) after the 1.17 freeze.

peter_l_downs 5y ago

Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX https://go2goplay.golang.org/p/krvTH1_7lwX

topspin 5y ago
Result[T] plus a ? operator to provide concision would be a huge win for Go.
nynx 5y ago
Result isn’t an enumeration of sorts?
- infogulch 5y ago
  No, Go doesn't have discriminated/tagged unions or valued-enumerations or whatever you want to call them, but generics let you hack them in without much trouble. Personally I'd take ADTs over generics any day, but it's not a dichotomy maybe we'll still get them some day. https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412
ramchip 5y ago
> Viewing and/or sharing code snippets is not available in your country for legal reasons. This message might also appear if your country is misdetected. If you believe this is an error, please file an issue. Wow, interesting. I'm in Japan.
- Cloudef 5y ago
  Works for me (also japan)
- Santosh83 5y ago
  Shame as a species we can't even share information (literally bits on the wire) globally, even if tangible goods and movements are circumscribed by political borders.

bitwize 5y ago

Now if they can shitcan the GC, Go might come within spitting distance of being competitive with Rust.

silisili 5y ago

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

_wldu 5y ago
I agree about placating. Go is fine as it is. I don't need or want generics, but the addition of generics won't stop me from using Go.
- silisili 5y ago
  It might me, in time. As mentioned, my main interest in Go is in how easily I can read others code. This kinda ruins that, even if I never use it.
  - tengbretson 5y ago
    Learning something is also an option.
    - silisili 5y ago
      Thank you.
    - jshen 5y ago
      Learning things outside of complex computer science topics often adds more value to the world. The ability to write useful programs without dedicating ones life to esoteric comp sci topics is a net positive for the world.
      - rustc 5y ago
        Are generics really considered as "esoteric comp sci topics"?

Taek 5y ago

Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.

5e92cb50239222b 5y ago
Even I know (not really being a heavy C++ user) that C++ doesn't have generics, it has templates, which is a much more powerful concept that's often overused.
- masklinn 5y ago
  > Even I know (not really being a heavy C++ user) that C++ doesn't have generics, it has templates So… you know wrong? Templates are a form of generics. What templates are not is an instance of parametric polymorphism.
papaf 5y ago
Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. The culture might help. I think generics in Java are not overused -- partly because they are not so powerful and partly because Java, similar to Go, did not have generics for a long time.
- randomdata 5y ago
  C++ also went a long time without generics, and even when support started to appear it was a separate code generation step, requiring even more time before we saw first-class compiler support. Powerful, though.
jrockway 5y ago
The key to readability is programming with readability in mind. Sure, languages play some part in that, but 90% of it is the programmer. Go is simple right now, and generics do complicate it, but even with the simplicity that Go has, people already make a giant mess of it. As soon as you get any advanced feature, people will abuse it -- colossal generic functions that take 5 interface{} arguments (but only ever operate on strings), one-off interfaces that have 35 methods, calling out to cgo just because they can, and giant tangles of goroutines, mutexes, semaphores, and sync.Pools all mixed together into one big ball of sadness. But, while everyone has the ability to create such a disaster area, some opt out and use the tool correctly -- making the advanced language features an asset instead of a liability. I don't think generics will change this; when used sparingly and at the right time for the right reason, it will make the code easier to read. I did a quick look through all my open source projects to see where I have accepted or returned an interface{} in my own APIs, which is a strong signal that I'm looking for generics, or am using a library that wants generics. One case is interacting with Kubernetes. I have two applications where I set up a reflector like `cache.NewReflector(lw, &v1.Node{}, store, resync)`, to keep a cache up to date; the implementation of "store" takes interface{} for all the arguments (Add, Delete, etc.), even though it only ever operates on a v1.Node. Generics will let me ensure at compile time that I only have to worry about v1.Node objects. Right now, that's handled with runtime assertions in the reflector itself, and in every implementation of the cache.Store. Generics clean this up. Another case that comes up is processing random JSON objects from the Internet with no defined schema. Those end up as map[string]interface{}, and that won't change. The last case is unmarshaling functions. I see some (in a JWT validation library) that are of the form `func Unmarshal(string) interface{}`. I don't really know what's going on there, and I don't know if generics will help. (Similarly, for the common case of unmarshaling JSON, I'm not sure generics can improve the `err := json.Unmarshal(bytes, &result)` API. I will have to look into it. That's about it.

tedunangst 5y ago

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

silisili 5y ago
Or good case study of squeaky wheels. I never wanted generics. I never thought to spam the development lists about how much I liked how things were going.
- bigdubs 5y ago
  a couple high profile projects (k8s) needed generics, there are limited use cases outlined in the planning docs that detail the holes in the language they're filling, it wasn't just squeaky wheels.
  - silisili 5y ago
    Shame how k8s was a failure without generics. Think what could have been.
    - Zababa 5y ago
      The thing is, Google is paying most of the development costs for Go and Google controls Go too. It makes sense to adapt the language to their needs. They already do stuff like creating new network protocols because it will reduce their costs.
      - loopz 5y ago
        Google have alternatives to k8s already. So it's more about making a market.
        Zababa 5y ago
        I've heard multiple times that Google Cloud has the best support for k8s, and that people moved to it because of that. Is that what you meant by making a market?

durbatuluk 5y ago

If you want all features of language X (I doubt we will stop at generics) use language X. Stop trying to make all languages the same. I work with programmers from OO background (java) and they can't even grasp the utility of functions as value or closures. Every damn "service" has an interface/generated mock and anemic model. They're desperate waiting for generics for go to "complete". I fear the influx of OO programmers.

chana_masala 5y ago
OO !== Generics, at all
- durbatuluk 5y ago
  I didn't say they're the same. I'm saying people coming from OO complain all the time of lack of generics, inheritance (besides composition) etc. I teach basic go at my job to help people wanting to migrate, they start the go journey thinking go will do "less" because we don't have all features as their main language. Which reminds me of this phrase: > 'You cannot reduce the complexity of your problem by increasing the complexity of your language.'

brundolf 5y ago

I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to. One thing I'm curious about: user-defined generics I can see going without, but the core language and standard library surely need to have them. How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code?

skybrian 5y ago
There are the usual operators and special functions like append(), which is implemented in the compiler and works on arbitrary slices. Not many of them, though. They are defined in the builtin pseudo-package: https://pkg.go.dev/builtin https://pkg.go.dev/builtin
takeda 5y ago
Java didn't have generics until version 5. They were added 8 years later.
- masklinn 5y ago
  c# was also released without generics, they wanted it out the door and the generics were not ready. They landed in 2.0.
- int_19h 5y ago
  Java didn't have user-defined generics, but it did have parametrized builtin types: arrays. Same thing for C#.
masklinn 5y ago
> How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code? They’re special-cased in the compiler, with bespoke implementations.

awinter-py 5y ago

those aren't generics they're from the canadian aboriginal syllabic block

erik_seaberg 5y ago
For anyone who doesn’t get it, https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_... was a pretty funny workaround.

ammmir 5y ago

the generics mafia has ruined rust and looks like go is next.

anothernewdude 5y ago
I shudder to think what Rust would look like without generics.

tannhaeuser 5y ago

Not entirely getting the hate/hype towards generics. What about run-time reflection and annotations, arguably an addition with more drastic consequences, and all things considered, not for the better IMO. Has anyone an opinion on using GraalVM/Java vs Golang?

tapirl 5y ago

Go needs custom generics for sure. But it is really a hurry-up to support custom generics for Go in version 1.18. Many problems have not been resolved yet. * should the builtin generics syntax be compatible with the new custom syntax * how many problems will be solved by the custom generics and how much complexities will be added. Is it a good balance?

int_19h 5y ago
The second question has been extensively answered by numerous mainstream languages adopting generics in the past, oh, 30 years or so?

jagger27 5y ago

Pretext: I love Go and write most of my day job code in it. To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. Little things like sorting will use generics pretty much transparently. All of the strongly typed code you write today that receives and returns concrete types will be just as valid tomorrow as it is today. Interfaces keep the same semantics and are a core part of how generics work. I think it’s important to remember that the people who design this language like it for the same reasons you do.

masklinn 5y ago
> To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. In fairness: just because that's true doesn't mean the libraries they like or need won't be migrating to generic facilities one way or an other, so they may be forced to the choice of interacting with generics or needing to reimplement their wheels (though also in fairness that's also common in the go ecosystem). > I think it’s important to remember that the people who design this language like it for the same reasons you do. That's not necessarily true, the designers of the language are not necessarily designing it for their use or like. See: Rob Pike's well known quotes on the target population for Go.

evanmoran 5y ago

This is actually my first week using go (from years of C++/Swift/js/etc) and I’ve been very impressed with the module system and simplicity so far. I’d definitely encourage others to try it if they haven’t. As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. It will still be only in one place, where as in C++ you could have hundreds of functions with the same name across many libraries and you just have to hope your ide knows which to step into.

masklinn 5y ago
> As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. There are already a number of langages with generics and without overloading (or defaults). Haskell, ocaml, rust, …
- 4ad 5y ago
  True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. In fact, once OCaml gets implicit modules, this won't be true anymore of OCaml either.
  - masklinn 5y ago
    > True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. That's no more overloading than Rust has through traits.
    - 4ad 5y ago
      It absolutely is, because class methods in Haskell are top level declarations. Not only this is not true in Rust, but it doesn't even matter as Rust doesn't have polymorphic values, only polymorphic types and functions. In Rust, unlike in Haskell or ML type inference stops at function boundary.

throwawaygo 5y ago

Sadly go is losing the spirit it was built with and alienating the experience that it needs to regain that spirit. This has been my top feedback every go survey is that it is being designed democratically where it needs to be led by experience.

deleted 5y ago
[deleted]

sascha_sl 5y ago

If you're really concerned about "clever developers", maybe you ought to ask for the removal of reflect and ast, because they've both been used to be way too clever about solving the same issue.

valenterry 5y ago
Correct. People will find a way to get rid of the verbosity and you either give them good tools to do it or you end up with a mess.

pjmlp 5y ago

Finally catching up modern times! Welcome to 1976.

shp0ngle 5y ago

Hey, instead of “return value, err”, we can now write it as generic Option! Kidding kidding, please don’t do it kids

valenterry 5y ago

Two thoughts: 1.) In a "simple language" (e.g. without generics) each line of code is easy to read/understand. But reading/understanding the whole program or application is difficult. In "not-simple languages" it's the other way around. 2.) An important criteria to judge the future of a language is how foresight the language authors have. I read that the go authors said in the past that they were not ready to add generics because they didn't know how to do so in a good way. True or not, retrospectively adding generics is not a great indicator for good language design to me. Even if the addition of generics is a net-positive thing, I expect that Go will go in the direction of C++, having a lot of accidental feature complexity in the language. I think it's better to do it like Lisp and keep a simple (but nonetheless flexible) core. Or do it like Haskell and design the language to elegantly allow as much abstraction as possible, moving carefully towards that goal. For these kind of languages, you better have people who have years long experience in exactly this: designing powerful programming languages. A developer can be the best in their own field, but they are doomed to fail when trying to build a future-proof, well designed programming language on their first attempt. (btw, not relating to the Go author's here) An example where this didn't work is Angular - from the first moment that I got in touch with it, I knew it was built by amateurs. It's only a framework, but the difference to a programming-language is minor in the case of these kind of all-encompassing frameworks. It is not surprising to me at all that the completely redesigned Angular later on.

smokey_circles 5y ago

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity", stay away from it if you don't like the "verbosity". These are both valid points, but they're subjective. Pushing it as fact is dishonest and self-serving, as well as eventually detrimental.

toolslive 5y ago
Go has generics. They're just not (yet) available for you. So to some it feels like a Tantalus punishment.
- ibraheemdev 5y ago
  If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up. [0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
  - masklinn 5y ago
    > If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. They're not generic (aka userland) generics, but they're still generics: parametric types, and functions able to work on them generically (you don't have a separate `append` function for every type you might put in a slice). > The generics proposal is being implemented from the ground up. Of course it is, the builtins are ad-hoc and half-assed. That doesn't mean they ain't a thing.
    - sagichmal 5y ago

mgraczyk 5y ago

Glad to see this finally happening. I've been writing a decent amount of Go lately and there are plenty of instances where this will make the code more readable.

ledneb 5y ago

What syntax did Go settle on, in the end?

ledneb 5y ago
Found it, I think https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...

deleted 5y ago

[deleted]

_ph_ 5y ago

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is, in a sense they are very comparable in my eyes). The interface concept is great for covering a lot of cases. That is, why so far, I have not missed generics much and was rather reluctant to the constant wishes to add them to the language. On the other side, there are cases, even if they are not very frequent, where generics do help a lot. Just the new slices package allone almost justifies the addition of generics. Furthermore, the proposal looks very much Go-like. As a consequence, I am quite looking forward to try them out and used responsibly[1], they can be a great addition to the Go universe. 1: I think the situation is somewhat similar to Lisp macros. Normally, a codebase rarely requires macros and readability is better, if you avoid creating too many macros. But occasionally there are situations, where using a macro tremendeously increases code quality. Both implementation and readability-wise. There macros should be used and it is great to have them available.

zarzavat 5y ago
I used to really hate Go's attitude to generics and type system features in general. I still do, but I appreciate that it's a matter of taste, and that different people have different tolerances for language complexity. People who like simplicity can use Go and people who like type systems can use Rust.
- pharmakom 5y ago
  Weird to think of Rust as an alternative to Go imo. C# and Java are more similar to Go (mostly due to GC), but with generics etc
papito 5y ago
I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost every other ecosystem can be absent in Go. Want to run setup code before your test suite? You on your own, buddy. And, oh yeah, 2/3 of your code will be `if err` statements, because exceptions are passé. I learned it by seeking out good Go codebases, which are incredibly rare. Hashi's Terraform comes to mind. Infamously, the early Kubernetes code was a nightmare because it lifted and shifted Java idioms and that was at the company that invented the Language. Or at Uber, where they passed on Go's native goroutines and channels in favor of homegrown concurrency, for SOME reason: https://eng.uber.com/go-geofence-highest-query-per-second-service/ https://eng.uber.com/go-geofence-highest-query-per-second-se... All this to show that Go is not a simple language to do well, so let's dispense with that myth. It has its uses, but having done it, I would never recommend Go for a greenfield project in my place of work - there are very few rules that come with it, and it requires tons of coordination and discipline among a team. And if you have to work with 2 or 3 other people who have strong opinions on how to do things in Go, watch out.

yawaramin 5y ago

I'm not a Go user; I don't consider it serious as a programming language. True, it has great tooling. It seems perfectly designed for certain groups of devs to bang out lower-level tools and utilities, and they love it for being such a great fit. That said, I think some of them may have a point that Go shouldn't actually try to tack on generics now. Consider that generics are only one piece of the puzzle when it comes to programming language power and abstraction capability. There are also ADTs, abstract types, pattern matching, immutability, lack of null, expression-oriented syntax, etc. Go with generics would be only one step along that journey of abstraction power. It would help the set of people who desperately need it to solve their code repetition and type-casting issues. But it would solve these problems just to clear the way for them to reach the next set of problems on the journey of abstraction.

amw-zero 5y ago

Generics introduce complexity. That’s pretty undeniable. There are also cases where generics provide much better solutions to problems. That is also undeniable. As someone who’s working in a Go codebase at work, I’m happy they added generics, especially in the way they did. It’s a pretty minimal subset of generic functionality. I will apply it in certain cases, mostly to reusable code. I think it’s a big win overall though, without introducing too much complexity to the language.