12 ms·

Golang generics proposal has been accepted

276 points by komuW 6y ago

maurys 6y ago
I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next "missing" thing.
- SeanLuke 6y ago
  > I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java's broken local variable closure semantics]. Sun (Oracle? forget) again picked the worst of the two proposals. Now we're stuck with a real monstrosity. Java has an amazing history of picking the wrong way to do things and permanently saddling developers with it.
  - wtetzner 6y ago
    > When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. Though using type erasure may have made the JVM a better target for other languages.
  - hota_mazi 6y ago
    Type erasure was the best of these options, and it's one of the main reasons why Java became even more successful than it already was, and also the main reason why there are so many languages created on top of the JVM (as opposed to .net, which supports reified generics, which complicates enormously writing languages on it, especially for interop reasons). More details: https://www.beust.com/weblog/erasure-vs-reification/ https://www.beust.com/weblog/erasure-vs-reification/
  - mauricioc 6y ago
    Since type erasure was mentioned, it's worth noting that Philip Wadler (of Haskell fame) was involved both in the design of Java generics [0] and of Go generics [1]. (Perhaps I should clarify that I don't have a strong opinion on type erasure.) [0] https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla.pdf https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla... [1] https://arxiv.org/abs/2005.11710 https://arxiv.org/abs/2005.11710
  - kaba0 6y ago
    Any objective reason for thinking either feature is bad?
- 015a 6y ago
  I think I'm ok with this as well. The developers behind Go have a really strong culture of taking a ton of time to implement any major language changes; very reminiscent of Java and C++. Talk around Generics began, well, when the language was first created, but even more seriously like five years ago, and it'll probably be another year before it hits production. I love this. Language changes need to be thought through considerably, with all angles considered, and by going slow it gives major developers time to give feedback, prepare, and most critically not always feel like the code they write will go out of date in three months. By comparison, writing anything in, say, Rust (and JavaScript ~four years ago, its better nowadays) feels exhausting, because its a constant battle with changing culture and evolving best practices. My favorite feature of Go is its characteristic of not carbon-dating codebases. Go written a decade ago looks almost the same as Go written today; Contexts would be the single major pseudo-language-level feature added in that interim which may give away newer code. Adding new features is still important, balance in all things etc, and code written after generics will give another epoch of carbon dating. Go strikes this balance in a way that should be a model for every other language.
- AnimalMuppet 6y ago
  > Once generics are implemented, I can imagine people requesting for the next "missing" thing. Perhaps. But there is (currently) no other feature that people have been whining about nearly as much as they have been whining about generics. So I think it's going to be a while before another need is felt to the same degree.
- novok 6y ago
  Golang is google's backup to java if oracle didn't let them have java anymore, with some additional design goals for large companies like fast build times, better memory usage and something jr engineers can pickup without much trouble. They both have garbage collection, they both perform about 3x slower than static C and they're both mostly used for network services, which is the same as Java at google.
  - kaba0 6y ago
    Go is AOT compiled, thus many many optimizations are not possible there. Also, 3x slower than C is a baseless claim for both; at least for Java, for comparable, big code sizes, Java will easily win, because mallocs are expensive, and arenas, pools whatevers are poor man’s GCs, with worse performance, and JIT compilation can do some really aggressive optimizations, as well as heap compression, etc.
2pEXgD0fZ5cF 6y ago
As someone who hasn't followed the discussion all this time, is there an up to date example of what the generics syntax will look like?
- 4ad 6y ago
  https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
  - 2pEXgD0fZ5cF 6y ago
    Thanks!
gautamcgoel 6y ago
This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob Pike) are at best ambivalent about this proposal and were outvoted. Personally, the proposal I was most excited about was to make ints be arbitrary precision by default. As someone who does a lot of math, this would have made Go much easier for me to use. Sadly, this proposal was scrapped a while back.
- opnitro 6y ago
  C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.
  - zwieback 6y ago
    For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way". Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.
    - f8o 6y ago
      I think that C# has a successfull implementation because it isn't just about syntax sugar. The runtime knows it. Generics+structs allows many optimizations.
      - zwieback 6y ago
        So true and portable across languages.
  - 6y ago
cies 6y ago
This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.
- lordofgibbons 6y ago
  Will it requires a VM to run? Also, how fast will this language build large projects?
  - cies 6y ago
    It will be like Go: no VM. And have great interop with Go! > Also, how fast will this language build large projects? Slightly slower. I wonder what the implementation of generics will do to Go's otherwise stellar compile times. A code base heavily using generics can easily be double the compile time. Not sure how this will be sold, probably "but then simply do not use it!"
    - erik_seaberg 6y ago
      I'm made out of meat, the compiler is always going to be millions of times faster than that. Are generics actually slower than codegen plus parsing the same method body over and over with different types?
      - cies 6y ago
        > meat Flesh to me. (vegan) :)
        erik_seaberg 6y ago
        Heh, it's a reference to https://www.mit.edu/people/dpolicar/writing/prose/text/thinkingMeat.html https://www.mit.edu/people/dpolicar/writing/prose/text/think...
deleted 6y ago
[deleted]
lastofus 6y ago
Out of curiosity, what changed between now, and when proposals for generics came up in years past?
- hnlmorg 6y ago
  This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options. Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.
  - meddlepal 6y ago
    Yea basically they're implementing Java-lite generics. I'm not sure what they have been waiting for exactly...
    - mseepgood 6y ago
      Java generics do type erasure, this proposal does not. Java generics do not work on primitive types or with operators, this proposal does. Java generics require unbounded parser look-ahead by using <>, this proposal avoids it by using []. These are just from the top of my head, I'm pretty sure there are more differences.
  - skybrian 6y ago
    I'm not sure what you're comparing to, but there were previous proposals that were pretty different (and worse in my opinion), and there were changes along the way in the drafts that eventually turned into the accepted proposal.
- wwarner 6y ago
  The main difference between the accepted proposal and the original proposal is that the original proposal introduced contracts and the accepted proposal folds all that functionality into interfaces.
hnlmorg 6y ago
I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.
- kyrra 6y ago
  It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w < x, y > (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?
  - hnlmorg 6y ago
    I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way that a lot of more readable languages lack. In the case of Go and the example you’ve given, if ‘W’ were a function then the code should read like this: a, b = w() < x, y > (z)
    - Jtsummers 6y ago
      In the example, we can't tell if w is a generic function or not (by looking at this line of code). Remove the spaces, as would be more conventional: w<x,y>(z) Is this two expressions on one line or one expression with two type parameters? Possible groupings: (w<x,y>)(z) // w is a generic function (w<x),(y>(z)) // two comparisons
    - blandflakes 6y ago
      The parens look like "helping ambiguous syntax" rather than "should read like this" here - if z is an argument to w, there was already a set of parens signifying the function call.
tick_tock_tick 6y ago
What does this mean for a timeline on when we can start using them?
- mseepgood 6y ago
  In a stable release maybe 1.18 (Feb 2022) or 1.19 (Aug 2022). In a beta release maybe 1.18 beta1 (Dec 2021).
smasher164 6y ago
This is a significant milestone for Go, and I'm extremely happy for the community. I didn't imagine getting here when I first started using the language, and yet here we are. Special props to Ian Lance Taylor and Robert Griesemer for their continued revisions of drafts, and exemplary discussion with the community in implementing feedback.
samuell 6y ago
Very much excited that this is finally moving forward. Such sweet improvements this will allow for SciPipe and FlowBase when this nears completion [1,2]. It will make it so much easier to enable typed port objects, which can still re-use all the handy functionality for connecting inports/outports, traversing the dataflow graph, etc etc. [1] https://scipipe.org https://scipipe.org [2] ihttps://flowbase.org https://flowbase.org
lalaithion 6y ago
Sad to see that we won't be getting type parameters on methods. I hope they fix the issues with it and can get that working in a future proposal.
baby 6y ago
I really really hope that this does not end up in people abusing generics in Golang code and making Golang code harder to read. The biggest argument of Golang in my opinion is that it is extremely easy to audit and read and understand at the moment.
- tiborsaas 6y ago
  Anything that can be abused in a language will be abused.
- karmakaze 6y ago
  When you get used to seeing it, the types mostly disappear from view until you look for it. I got to that level with Java, and Kotlin for the most part--never with Scala it always looked like line noise.
deleted 6y ago
[deleted]
- deleted 6y ago
  [deleted]
midrus 6y ago
"We don't need generics" "We don't need exceptions" "We don't need ORMs"
- coldtea 6y ago
  2 out of 3 right ain't bad. We really don't need ORMs
  - midrus 6y ago
    Yep, I can see at work how fantastic are those hand written sql scripts wrapped in bash to run migrations, and those magnific joins and manual mapping of dates. That's great, until you realize you have an actual product to build.
    - coldtea 6y ago
      Well, no ORM != bash. And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. (Also a query builder is not an ORM). >That's great, until you realize you have an actual product to build. That's exactly the problem with ORMs. You get worse SQL generated under the scenes, with worse performance, and less control. It's just hidden under the carpet. Plus, if you build your product with heavy domain objects in 2000s OO-style you're doing it wrong. And if you don't, and use, e.g. data classes and record structures, then you don't need an ORM since there's no "O" to map too.
      - midrus 6y ago
        All of this is an immense wheel reinvention, and the SQL I'm seeing is actually far worse than what ActiveRecord or Django's ORM would generate. Also, talking about such a low level performance issues makes me think we're already talking about very different problems. Maybe you're working for Google or Amazon or a pretty performance heavy application. Then ok, I agree with you. But my disconfort is with most startups, and most average companies chosing Go and doing all of this reinvention when what they are doing is basic CRUD for a web app that has less than 100 reqs a day. For the use cases I've seen of Go so far, the bottleneck was caused by using it, and it's ecosystem, because the slowest part of the system is the development time and the need to rebuild from scratch a lot of things you get for free otherwise.
zxcvbn4038 6y ago
Nobody will have anything to complain about once go has generics, we'll never hear about Golang on Hacker News again! It'll just be the Rust people complaining. ;)
- erik_seaberg 6y ago
  There’s always error handling.
- pjmlp 6y ago
  Error handling, lack of enums, modules, too big executatbles, lack of optimizing backend, middle class GC implementation.
  - andreygrehov 6y ago
    Error handling - I'm a huge fan of explicit error handling. You know exactly what's going to happen. Lack of enums - not big of a deal. Never had any issues with defining an enum-like type, which is a common idiom in Go. Modules - it has been fixed. Are there any issues left? Too big executatbles - I mean, ok, so what? Why is it a concern? Lack of optimizing backend - could you elaborate on that? Middle class GC implementation - are you referring to lack of manual tuning?
    - zxcvbn4038 6y ago
      https://www.psychologytoday.com/us/blog/women-autism-spectrum-disorder/202009/5-signs-you-might-be-drama-queen https://www.psychologytoday.com/us/blog/women-autism-spectru...
dcolkitt 6y ago
IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large codebase can require a huge footprint of lines modified, just because so much code winds up duplicated in slightly different contexts. That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. I don't know if there's any theoretical reason for it to hold, but more typing complexity inevitably leads to slow compile times. And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Even templates in C++ are notorious for puking near impossible to decipher errors. This is something I'm sure can be fixed with enough engineering effort, but it would probably take a lot of effort to get there. In general, I bitch about the Go language all the time. But I think we should recognize that the simplicity of the language gives us developers a lot of peripheral really nice usability benefits.
- SloopJon 6y ago
  > Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
  - bcrosby95 6y ago
    This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.
otabdeveloper4 6y ago
Nice to know. So what's the timeline for proper exceptions now?
dang 6y ago
A few days ago: https://news.ycombinator.com/item?id=26018649 https://news.ycombinator.com/item?id=26018649 A few weeks ago: https://news.ycombinator.com/item?id=25750582 https://news.ycombinator.com/item?id=25750582
deleted 6y ago
[deleted]
wmil 6y ago
I'm kind of sad that they didn't allow you to use inuktitut characters as a joke about this classic comment. https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
_spoonman 6y ago
Is generics akin to overloading functions?
- manu3000 6y ago
  no, overloading functions is called "ad hoc polymorphism", whereas generics is called "parametric polymorphism"
pjmlp 6y ago
Finally! At least one pain point less when dealing with Docker/K8s eco-system.
andreygrehov 6y ago
How are generics implemented under the hood? Reflection?

276 points by komuW 6y ago

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next "missing" thing.

SeanLuke 6y ago
> I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java's broken local variable closure semantics]. Sun (Oracle? forget) again picked the worst of the two proposals. Now we're stuck with a real monstrosity. Java has an amazing history of picking the wrong way to do things and permanently saddling developers with it.
- wtetzner 6y ago
  > When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. Though using type erasure may have made the JVM a better target for other languages.
- hota_mazi 6y ago
  Type erasure was the best of these options, and it's one of the main reasons why Java became even more successful than it already was, and also the main reason why there are so many languages created on top of the JVM (as opposed to .net, which supports reified generics, which complicates enormously writing languages on it, especially for interop reasons). More details: https://www.beust.com/weblog/erasure-vs-reification/ https://www.beust.com/weblog/erasure-vs-reification/
- mauricioc 6y ago
  Since type erasure was mentioned, it's worth noting that Philip Wadler (of Haskell fame) was involved both in the design of Java generics [0] and of Go generics [1]. (Perhaps I should clarify that I don't have a strong opinion on type erasure.) [0] https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla.pdf https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla... [1] https://arxiv.org/abs/2005.11710 https://arxiv.org/abs/2005.11710
- kaba0 6y ago
  Any objective reason for thinking either feature is bad?
015a 6y ago
I think I'm ok with this as well. The developers behind Go have a really strong culture of taking a ton of time to implement any major language changes; very reminiscent of Java and C++. Talk around Generics began, well, when the language was first created, but even more seriously like five years ago, and it'll probably be another year before it hits production. I love this. Language changes need to be thought through considerably, with all angles considered, and by going slow it gives major developers time to give feedback, prepare, and most critically not always feel like the code they write will go out of date in three months. By comparison, writing anything in, say, Rust (and JavaScript ~four years ago, its better nowadays) feels exhausting, because its a constant battle with changing culture and evolving best practices. My favorite feature of Go is its characteristic of not carbon-dating codebases. Go written a decade ago looks almost the same as Go written today; Contexts would be the single major pseudo-language-level feature added in that interim which may give away newer code. Adding new features is still important, balance in all things etc, and code written after generics will give another epoch of carbon dating. Go strikes this balance in a way that should be a model for every other language.
AnimalMuppet 6y ago
> Once generics are implemented, I can imagine people requesting for the next "missing" thing. Perhaps. But there is (currently) no other feature that people have been whining about nearly as much as they have been whining about generics. So I think it's going to be a while before another need is felt to the same degree.
novok 6y ago
Golang is google's backup to java if oracle didn't let them have java anymore, with some additional design goals for large companies like fast build times, better memory usage and something jr engineers can pickup without much trouble. They both have garbage collection, they both perform about 3x slower than static C and they're both mostly used for network services, which is the same as Java at google.
- kaba0 6y ago
  Go is AOT compiled, thus many many optimizations are not possible there. Also, 3x slower than C is a baseless claim for both; at least for Java, for comparable, big code sizes, Java will easily win, because mallocs are expensive, and arenas, pools whatevers are poor man’s GCs, with worse performance, and JIT compilation can do some really aggressive optimizations, as well as heap compression, etc.

2pEXgD0fZ5cF 6y ago

As someone who hasn't followed the discussion all this time, is there an up to date example of what the generics syntax will look like?

4ad 6y ago
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
- 2pEXgD0fZ5cF 6y ago
  Thanks!

gautamcgoel 6y ago

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob Pike) are at best ambivalent about this proposal and were outvoted. Personally, the proposal I was most excited about was to make ints be arbitrary precision by default. As someone who does a lot of math, this would have made Go much easier for me to use. Sadly, this proposal was scrapped a while back.

opnitro 6y ago
C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.
- zwieback 6y ago
  For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way". Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.
  - f8o 6y ago
    I think that C# has a successfull implementation because it isn't just about syntax sugar. The runtime knows it. Generics+structs allows many optimizations.
    - zwieback 6y ago
      So true and portable across languages.
- 6y ago

cies 6y ago

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

lordofgibbons 6y ago
Will it requires a VM to run? Also, how fast will this language build large projects?
- cies 6y ago
  It will be like Go: no VM. And have great interop with Go! > Also, how fast will this language build large projects? Slightly slower. I wonder what the implementation of generics will do to Go's otherwise stellar compile times. A code base heavily using generics can easily be double the compile time. Not sure how this will be sold, probably "but then simply do not use it!"
  - erik_seaberg 6y ago
    I'm made out of meat, the compiler is always going to be millions of times faster than that. Are generics actually slower than codegen plus parsing the same method body over and over with different types?
    - cies 6y ago
      > meat Flesh to me. (vegan) :)
      - erik_seaberg 6y ago
        Heh, it's a reference to https://www.mit.edu/people/dpolicar/writing/prose/text/thinkingMeat.html https://www.mit.edu/people/dpolicar/writing/prose/text/think...

deleted 6y ago

[deleted]

lastofus 6y ago

Out of curiosity, what changed between now, and when proposals for generics came up in years past?

hnlmorg 6y ago
This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options. Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.
- meddlepal 6y ago
  Yea basically they're implementing Java-lite generics. I'm not sure what they have been waiting for exactly...
  - mseepgood 6y ago
    Java generics do type erasure, this proposal does not. Java generics do not work on primitive types or with operators, this proposal does. Java generics require unbounded parser look-ahead by using <>, this proposal avoids it by using []. These are just from the top of my head, I'm pretty sure there are more differences.
- skybrian 6y ago
  I'm not sure what you're comparing to, but there were previous proposals that were pretty different (and worse in my opinion), and there were changes along the way in the drafts that eventually turned into the accepted proposal.
wwarner 6y ago
The main difference between the accepted proposal and the original proposal is that the original proposal introduced contracts and the accepted proposal folds all that functionality into interfaces.

hnlmorg 6y ago

I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.

kyrra 6y ago
It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w < x, y > (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?
- hnlmorg 6y ago
  I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way that a lot of more readable languages lack. In the case of Go and the example you’ve given, if ‘W’ were a function then the code should read like this: a, b = w() < x, y > (z)
  - Jtsummers 6y ago
    In the example, we can't tell if w is a generic function or not (by looking at this line of code). Remove the spaces, as would be more conventional: w<x,y>(z) Is this two expressions on one line or one expression with two type parameters? Possible groupings: (w<x,y>)(z) // w is a generic function (w<x),(y>(z)) // two comparisons
  - blandflakes 6y ago
    The parens look like "helping ambiguous syntax" rather than "should read like this" here - if z is an argument to w, there was already a set of parens signifying the function call.

tick_tock_tick 6y ago

What does this mean for a timeline on when we can start using them?

mseepgood 6y ago
In a stable release maybe 1.18 (Feb 2022) or 1.19 (Aug 2022). In a beta release maybe 1.18 beta1 (Dec 2021).

smasher164 6y ago

This is a significant milestone for Go, and I'm extremely happy for the community. I didn't imagine getting here when I first started using the language, and yet here we are. Special props to Ian Lance Taylor and Robert Griesemer for their continued revisions of drafts, and exemplary discussion with the community in implementing feedback.

samuell 6y ago

Very much excited that this is finally moving forward. Such sweet improvements this will allow for SciPipe and FlowBase when this nears completion [1,2]. It will make it so much easier to enable typed port objects, which can still re-use all the handy functionality for connecting inports/outports, traversing the dataflow graph, etc etc. [1] https://scipipe.org https://scipipe.org [2] ihttps://flowbase.org https://flowbase.org

lalaithion 6y ago

Sad to see that we won't be getting type parameters on methods. I hope they fix the issues with it and can get that working in a future proposal.

baby 6y ago

I really really hope that this does not end up in people abusing generics in Golang code and making Golang code harder to read. The biggest argument of Golang in my opinion is that it is extremely easy to audit and read and understand at the moment.

tiborsaas 6y ago
Anything that can be abused in a language will be abused.
karmakaze 6y ago
When you get used to seeing it, the types mostly disappear from view until you look for it. I got to that level with Java, and Kotlin for the most part--never with Scala it always looked like line noise.

deleted 6y ago

[deleted]

deleted 6y ago
[deleted]

midrus 6y ago

"We don't need generics" "We don't need exceptions" "We don't need ORMs"

coldtea 6y ago
2 out of 3 right ain't bad. We really don't need ORMs
- midrus 6y ago
  Yep, I can see at work how fantastic are those hand written sql scripts wrapped in bash to run migrations, and those magnific joins and manual mapping of dates. That's great, until you realize you have an actual product to build.
  - coldtea 6y ago
    Well, no ORM != bash. And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. (Also a query builder is not an ORM). >That's great, until you realize you have an actual product to build. That's exactly the problem with ORMs. You get worse SQL generated under the scenes, with worse performance, and less control. It's just hidden under the carpet. Plus, if you build your product with heavy domain objects in 2000s OO-style you're doing it wrong. And if you don't, and use, e.g. data classes and record structures, then you don't need an ORM since there's no "O" to map too.
    - midrus 6y ago
      All of this is an immense wheel reinvention, and the SQL I'm seeing is actually far worse than what ActiveRecord or Django's ORM would generate. Also, talking about such a low level performance issues makes me think we're already talking about very different problems. Maybe you're working for Google or Amazon or a pretty performance heavy application. Then ok, I agree with you. But my disconfort is with most startups, and most average companies chosing Go and doing all of this reinvention when what they are doing is basic CRUD for a web app that has less than 100 reqs a day. For the use cases I've seen of Go so far, the bottleneck was caused by using it, and it's ecosystem, because the slowest part of the system is the development time and the need to rebuild from scratch a lot of things you get for free otherwise.

zxcvbn4038 6y ago

Nobody will have anything to complain about once go has generics, we'll never hear about Golang on Hacker News again! It'll just be the Rust people complaining. ;)

erik_seaberg 6y ago
There’s always error handling.
pjmlp 6y ago
Error handling, lack of enums, modules, too big executatbles, lack of optimizing backend, middle class GC implementation.
- andreygrehov 6y ago
  Error handling - I'm a huge fan of explicit error handling. You know exactly what's going to happen. Lack of enums - not big of a deal. Never had any issues with defining an enum-like type, which is a common idiom in Go. Modules - it has been fixed. Are there any issues left? Too big executatbles - I mean, ok, so what? Why is it a concern? Lack of optimizing backend - could you elaborate on that? Middle class GC implementation - are you referring to lack of manual tuning?
  - zxcvbn4038 6y ago
    https://www.psychologytoday.com/us/blog/women-autism-spectrum-disorder/202009/5-signs-you-might-be-drama-queen https://www.psychologytoday.com/us/blog/women-autism-spectru...

dcolkitt 6y ago

IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large codebase can require a huge footprint of lines modified, just because so much code winds up duplicated in slightly different contexts. That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. I don't know if there's any theoretical reason for it to hold, but more typing complexity inevitably leads to slow compile times. And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Even templates in C++ are notorious for puking near impossible to decipher errors. This is something I'm sure can be fixed with enough engineering effort, but it would probably take a lot of effort to get there. In general, I bitch about the Go language all the time. But I think we should recognize that the simplicity of the language gives us developers a lot of peripheral really nice usability benefits.

SloopJon 6y ago
> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
- bcrosby95 6y ago
  This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.

otabdeveloper4 6y ago

Nice to know. So what's the timeline for proper exceptions now?

dang 6y ago

A few days ago: https://news.ycombinator.com/item?id=26018649 https://news.ycombinator.com/item?id=26018649 A few weeks ago: https://news.ycombinator.com/item?id=25750582 https://news.ycombinator.com/item?id=25750582

deleted 6y ago

[deleted]

wmil 6y ago

I'm kind of sad that they didn't allow you to use inuktitut characters as a joke about this classic comment. https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

_spoonman 6y ago

Is generics akin to overloading functions?

manu3000 6y ago
no, overloading functions is called "ad hoc polymorphism", whereas generics is called "parametric polymorphism"

pjmlp 6y ago

Finally! At least one pain point less when dealing with Docker/K8s eco-system.

andreygrehov 6y ago

How are generics implemented under the hood? Reflection?