24 ms·

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, con

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones. This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. I wonder if Go's historical antipathy towards this feature has driven away most of the people who would want it, or if there is still enough latent desire for generics that serious Go users will be able to produce the necessary mountain of real-world use cases to get something going here.

TheDong 9y ago
The fact that go1.9 will include a "sync.Map" type which should be generic, but can't be due to the language's limitations should already answer that. See also all of the "container" portion of the stdlib: https://golang.org/pkg/container/ https://golang.org/pkg/container/ All of those should be generic, but aren't. Clearly there's already sufficient demand for generic collections just based on the stdlib and the fact sync.Map was seen as needed.
- piinbinary 9y ago
  I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.
- xienze 9y ago
  > All of those should be generic, but aren't. They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!" The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.
  - bpicolo 9y ago
    I mean, having to cast after every single call to heap is a problem. Go is turing complete already, so all problems are already able to be solved. :)
- jadbox 9y ago
  Agree- having map, filter, reduce with strong type guarantees will be a huge boon. Imagine being able to map over a collection and the code hints will understand the new output types in the chain. This is something you cannot have when your higher order ops are all typed to Interface {}.
  - djur 9y ago
    Unfortunately, Go is a language whose original creator is of the opinion that map/filter/reduce are just ways to make your program "fit on one line"[1], and that you should just use a for loop[2]. [1]: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... [2]: https://github.com/robpike/filter https://github.com/robpike/filter
- maxekman 9y ago
  The sync.Map case for generics is a perfect example. Thanks for bringing it up.
- jerf 9y ago
  "All of those should be generic, but aren't." I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use. It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.
crawshaw 9y ago
Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.
- kyrra 9y ago
  Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.
- pjmlp 9y ago
  Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.
  - masklinn 9y ago
    > Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.
    - _old_dude_ 9y ago
      C# does generics specialization at runtime, hard to do if you have no JIT :)
      - davidp 9y ago
        Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
callesgg 9y ago
Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.
- weberc2 9y ago
  Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...
  - callesgg 9y ago
    In my specific case it was the fact that i could not have one insert function or one update function. I would need one for each and every struct(table). These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler https://github.com/vattle/sqlboiler So from the ORM perspective we (as the community) have worked around it.
    - staofbur 9y ago
      This is incidentally where .Net was around the 1.1 release (2003ish) We had code generation frameworks kicking out swathes of boiler plate. Now Repository<T> and for us around 200,000 lines of code are gone and only one narrow set of tests to execute.
    - slantedview 9y ago
      The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.
      - weberc2 9y ago
        He wasn't making that argument...
zerr 9y ago
They should look up the usage of empty interfaces [in the wild or in-house].
- munificent 9y ago
  This is a great point. Other analysis one could do: 1. Look at uses of cast operators in a codebase. How many of those would be eliminated by making the surrounding operation generic? 2. Go through the language spec and see how many features could be moved out of the language and into the core library if generics were supported.
tomovo 9y ago
Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.
- tomovo 9y ago
  More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.
  - eropple 9y ago
    Both C# and Java have taken different approaches to constrained generics that are still really useful for about...I dunno, the 90% case (C# has reified generics and so it's more like 95%, but type erasure also has its pluses when you're off-roading around in a framework somewhere). Scala goes a little further and covers, like, the 99% case, and plenty of inadvisable ones too.
  - int_19h 9y ago
    C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).
    - tomovo 9y ago
      So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?
      - pjmlp 9y ago
        .NET does a mixture of C++ and Java, meaning generic instatiations for value types get their own version of the code, instatiations for reference types get a shared version.
HarkMamilton 9y ago
I think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?
- cat199 9y ago
  This presumes that: a) generic programming is a new thing b) any of those people you mention aren't using go for some things and other things where this feature is desired c) that the feature will 'at best' be at level X d) that level X won't be enough to satisfy some use cases and a whole host of other things, not least of which the fact that go itself was invented to suit some purpose after other languages existed, and has been successful for many users
- matthewowen 9y ago
  Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.
  - resf 9y ago
    The opposite side of that coin is that other programming languages do already exist. Any new language is already playing catch-up to reach the state of the art. Go is 10 years old and in those 10 years has made astonishingly little progress at implementing basic features such as error handling, because the designers cannot escape their bubble. The most sensible thing to do is to kill Go, not to improve it. The root problem is not the lack of this or that feature, but the bizarre beliefs of the people running the project.
    - johnwilkesbooth 9y ago
      > The most sensible thing to do is to kill Go, not to improve it. Care to expand this? It's pretty clear that you don't find Go suitable for your own use cases, but I've found it to be an extremely productive language, despite the fact that it may have a couple of warts.
wheaties 9y ago
If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!
- masklinn 9y ago
  > perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)
  - endymi0n 9y ago
    Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
    - masklinn 9y ago
      > Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.
solomatov 9y ago
I would start using Go in my projects if it introduces generics. It's a show stopper for me.
- Spiritus 9y ago
  The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.
  - Touche 9y ago
    Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.
    - Spiritus 9y ago
      Did you even read the blog post? Such feedback was explicitly asked for.
      - AaronFriel 9y ago
        I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable. What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind? To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems? I doubt it.
        9y ago
xienze 9y ago
> This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. Nah, this is pretty much the same answer they've been giving all along, lots of handwaving about how generics are so cutting edge that no one can figure out how to use them effectively yet ("we just can't wrap our heads around this crazy idea!") In other words, don't count on them in Go 2.
stormbrew 9y ago
If I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics. It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.
- liveoneggs 9y ago
  the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way. basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.
  - grey-area 9y ago
    As a maintainer, you're bombarded with reasonable requests (I think around 10 a day on the Go project). Part of your job is to turn down hundreds of these and pick the few that benefit the most people from a diverse set of users, and also don't break anything or extend the api surface too much. Then whatever you choose people complain vociferously. Sometimes good requests get ignored in that noise. Choosing is hard, and while they could improve I think the Go maintners have done a pretty good job, and are willing to admit mistakes.
    - rattray 9y ago
      > and are willing to admit mistakes. Admitting a mistake on "generics" would probably go a long way towards credibility for the team. No matter how many excellent decisions they've made that have delicately balanced opinions and tradeoffs, this one hasn't gone over well, and it's very widely known.
saghm 9y ago
I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handling and traditional exceptions.
- imsofuture 9y ago
  Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.
  - acdha 9y ago
    Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?
    - imsofuture 9y ago
      No, but that's what I mean as intentionally ignoring.
    - growse 9y ago
      No, because using `foo, _` you're explicitly saying that you don't care about the error.
  - hdhzy 9y ago
    So... Just like checked exceptions in Java?
    - imsofuture 9y ago
      Yes, it's somewhat similar in that the compiler checks if you have handled or chosen not to handle an error. You're not allowed to ignore it (through omission).
untog 9y ago
It strikes me as a pretty odd statement, though. I'll admit that I'm not very familiar with Go, but surely you can look back at the benefits of generics in other languages? Go is hardly so specialised that you can't learn a single lesson from elsewhere.
- Touche 9y ago
  I agree, I didn't find the statement refreshing at all, I found it insulting. You damn well know the use-cases for generics. If you still don't like it; fine, say that explicitly. Don't pussyfoot around it and play the "we just don't know that much about it yet" lie.
coldtea 9y ago
>This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. It seems to me to be the same "Generics is some foreign concept we just heard of, and we're not sure how to implement them in Go yet, but we'll consider it if we chance upon some magical optimal way" that has been the official party line of Go since forever... Even the "we are asking you for proposals" part has been there since a decade or so...
pjmlp 9y ago
I would already be happy if they supported generics like CLU did in 1975, no need for nothing too fancy.
anth1988 9y ago
This is just another way of saying fuck generics. They really can't see any solvable problems after years of people asking for generics?
slantedview 9y ago
The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.
- 43224gg252 9y ago
  Then why don't you come up with a legitimate use case?
  - treehau5 9y ago
    I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed them, and once was because a library forced me to.
    - slantedview 9y ago
      > Everyone wants generics, no one knows why This is such a troll'ish statement, but I'll respond anyways because maybe you actually are just that uninformed. Without generics any number of libraries that utilize generic function blocks - Func [1] in C#, Callable [2] in Java, etc., and do things like return the function's type parameter as a method result, would not be possible. This is exceedingly common, at least in libraries. If you want to know how common, let me refer you to my friend http://google.com http://google.com. Just because something isn't valuable to you, personally, doesn't mean it's not valuable. As in all aspects of life, not everyone is you. 1. https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).... 2. https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Callable.html https://docs.oracle.com/javase/7/docs/api/java/util/concurre...
      - deleted 9y ago
kernelbandwidth 9y ago
The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns. Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.
- erikpukinskis 9y ago
  This suggests that both generics and inheritance are unnecessary.
  - kccqzy 9y ago
    It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.
    - XorNot 9y ago
      Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them? On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project velocity because when we need to prototype a new requirement, the push back has been paraphrasing "oh, could you not do that in <core product> and handle it somewhere else?" - so we end up with a bunch of shell scripts cobbled together to do so.
vec 9y ago
I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn<T>` instead of half a dozen variations on `sql.NullWhatever`) * 99% of functions that accept or return `interface{}` I appreciate that they seem open to the idea for v2, but "the use case isn't clear" is absurdly out of touch with the community. Using `interface{}` to temporarily escape the type system and copy/pasting functions just to adjust the signature a bit were among the first go idioms I learned, and they both exist solely to work around the lack of generics.
- zemo 9y ago
  > I'm not even a Go developer > Using `interface{}` to temporarily escape the type system tbh if you program Go correctly, you use interface{} pretty rarely.
  - camus2 9y ago
    > tbh if you program Go correctly, you use interface{} pretty rarely. It's a bit like saying "if you program C correctly, you use (void *) pretty rarely.". that's not the case, Go maintainers themselves keep on adding API with interface {} everywhere. Are you saying they are not programming Go correctly?
- spyspy 9y ago
  It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.
  - rbehrends 9y ago
    The same argument applies, mutatis mutandis, to imperative iteration constructs such as range.
hota_mazi 9y ago
That's a charitable way to look at the comment. My more cynical reaction is that someone who doesn't understand the benefit of generics or can't even come up with examples where generics are superior to their alternative should not be allowed anywhere near a language design discussion.
kccqzy 9y ago
Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464
- kccqzy 9y ago
  It really reminds me of early C macros where people use the ## operator to synthesize monomorphized versions.
  - fanf2 9y ago
    The ## operator is an ANSI C feature, so not really "early". In pre-ANSI preprocessors you had to abuse the lexer to paste tokens, e.g. by relying on // being deleted - nowadays comments are replaced by space.
- stefantalpalaru 9y ago
  > Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464 Generics and Go: https://github.com/stefantalpalaru/golib-nim https://github.com/stefantalpalaru/golib-nim
- zyxzkz 9y ago
  That's an awesome trick, using angle brackets that aren't angle brackets!

TheDong 9y ago

The fact that go1.9 will include a "sync.Map" type which should be generic, but can't be due to the language's limitations should already answer that. See also all of the "container" portion of the stdlib: https://golang.org/pkg/container/ https://golang.org/pkg/container/ All of those should be generic, but aren't. Clearly there's already sufficient demand for generic collections just based on the stdlib and the fact sync.Map was seen as needed.

piinbinary 9y ago
I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.
xienze 9y ago
> All of those should be generic, but aren't. They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!" The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.
- bpicolo 9y ago
  I mean, having to cast after every single call to heap is a problem. Go is turing complete already, so all problems are already able to be solved. :)
jadbox 9y ago
Agree- having map, filter, reduce with strong type guarantees will be a huge boon. Imagine being able to map over a collection and the code hints will understand the new output types in the chain. This is something you cannot have when your higher order ops are all typed to Interface {}.
- djur 9y ago
  Unfortunately, Go is a language whose original creator is of the opinion that map/filter/reduce are just ways to make your program "fit on one line"[1], and that you should just use a for loop[2]. [1]: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... [2]: https://github.com/robpike/filter https://github.com/robpike/filter
maxekman 9y ago
The sync.Map case for generics is a perfect example. Thanks for bringing it up.
jerf 9y ago
"All of those should be generic, but aren't." I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use. It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.

crawshaw 9y ago

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

kyrra 9y ago
Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.
pjmlp 9y ago
Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.
- masklinn 9y ago
  > Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.
  - _old_dude_ 9y ago
    C# does generics specialization at runtime, hard to do if you have no JIT :)
    - davidp 9y ago
      Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

callesgg 9y ago

Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.

weberc2 9y ago
Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...
- callesgg 9y ago
  In my specific case it was the fact that i could not have one insert function or one update function. I would need one for each and every struct(table). These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler https://github.com/vattle/sqlboiler So from the ORM perspective we (as the community) have worked around it.
  - staofbur 9y ago
    This is incidentally where .Net was around the 1.1 release (2003ish) We had code generation frameworks kicking out swathes of boiler plate. Now Repository<T> and for us around 200,000 lines of code are gone and only one narrow set of tests to execute.
  - slantedview 9y ago
    The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.
    - weberc2 9y ago
      He wasn't making that argument...

zerr 9y ago

They should look up the usage of empty interfaces [in the wild or in-house].

munificent 9y ago
This is a great point. Other analysis one could do: 1. Look at uses of cast operators in a codebase. How many of those would be eliminated by making the surrounding operation generic? 2. Go through the language spec and see how many features could be moved out of the language and into the core library if generics were supported.

tomovo 9y ago

Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.

tomovo 9y ago
More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.
- eropple 9y ago
  Both C# and Java have taken different approaches to constrained generics that are still really useful for about...I dunno, the 90% case (C# has reified generics and so it's more like 95%, but type erasure also has its pluses when you're off-roading around in a framework somewhere). Scala goes a little further and covers, like, the 99% case, and plenty of inadvisable ones too.
- int_19h 9y ago
  C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).
  - tomovo 9y ago
    So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?
    - pjmlp 9y ago
      .NET does a mixture of C++ and Java, meaning generic instatiations for value types get their own version of the code, instatiations for reference types get a shared version.

HarkMamilton 9y ago

I think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?

cat199 9y ago
This presumes that: a) generic programming is a new thing b) any of those people you mention aren't using go for some things and other things where this feature is desired c) that the feature will 'at best' be at level X d) that level X won't be enough to satisfy some use cases and a whole host of other things, not least of which the fact that go itself was invented to suit some purpose after other languages existed, and has been successful for many users
matthewowen 9y ago
Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.
- resf 9y ago
  The opposite side of that coin is that other programming languages do already exist. Any new language is already playing catch-up to reach the state of the art. Go is 10 years old and in those 10 years has made astonishingly little progress at implementing basic features such as error handling, because the designers cannot escape their bubble. The most sensible thing to do is to kill Go, not to improve it. The root problem is not the lack of this or that feature, but the bizarre beliefs of the people running the project.
  - johnwilkesbooth 9y ago
    > The most sensible thing to do is to kill Go, not to improve it. Care to expand this? It's pretty clear that you don't find Go suitable for your own use cases, but I've found it to be an extremely productive language, despite the fact that it may have a couple of warts.

wheaties 9y ago

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

masklinn 9y ago
> perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)
- endymi0n 9y ago
  Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
  - masklinn 9y ago
    > Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.

solomatov 9y ago

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Spiritus 9y ago
The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.
- Touche 9y ago
  Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.
  - Spiritus 9y ago
    Did you even read the blog post? Such feedback was explicitly asked for.
    - AaronFriel 9y ago
      I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable. What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind? To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems? I doubt it.
      - 9y ago

xienze 9y ago

> This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. Nah, this is pretty much the same answer they've been giving all along, lots of handwaving about how generics are so cutting edge that no one can figure out how to use them effectively yet ("we just can't wrap our heads around this crazy idea!") In other words, don't count on them in Go 2.

stormbrew 9y ago

If I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics. It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.

liveoneggs 9y ago
the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way. basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.
- grey-area 9y ago
  As a maintainer, you're bombarded with reasonable requests (I think around 10 a day on the Go project). Part of your job is to turn down hundreds of these and pick the few that benefit the most people from a diverse set of users, and also don't break anything or extend the api surface too much. Then whatever you choose people complain vociferously. Sometimes good requests get ignored in that noise. Choosing is hard, and while they could improve I think the Go maintners have done a pretty good job, and are willing to admit mistakes.
  - rattray 9y ago
    > and are willing to admit mistakes. Admitting a mistake on "generics" would probably go a long way towards credibility for the team. No matter how many excellent decisions they've made that have delicately balanced opinions and tradeoffs, this one hasn't gone over well, and it's very widely known.

saghm 9y ago

I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handling and traditional exceptions.

imsofuture 9y ago
Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.
- acdha 9y ago
  Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?
  - imsofuture 9y ago
    No, but that's what I mean as intentionally ignoring.
  - growse 9y ago
    No, because using `foo, _` you're explicitly saying that you don't care about the error.
- hdhzy 9y ago
  So... Just like checked exceptions in Java?
  - imsofuture 9y ago
    Yes, it's somewhat similar in that the compiler checks if you have handled or chosen not to handle an error. You're not allowed to ignore it (through omission).

untog 9y ago

It strikes me as a pretty odd statement, though. I'll admit that I'm not very familiar with Go, but surely you can look back at the benefits of generics in other languages? Go is hardly so specialised that you can't learn a single lesson from elsewhere.

Touche 9y ago
I agree, I didn't find the statement refreshing at all, I found it insulting. You damn well know the use-cases for generics. If you still don't like it; fine, say that explicitly. Don't pussyfoot around it and play the "we just don't know that much about it yet" lie.

coldtea 9y ago

>This is a much more nuanced position than the Go team has expressed in the past, which amounted to "fuck generics," but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. It seems to me to be the same "Generics is some foreign concept we just heard of, and we're not sure how to implement them in Go yet, but we'll consider it if we chance upon some magical optimal way" that has been the official party line of Go since forever... Even the "we are asking you for proposals" part has been there since a decade or so...

pjmlp 9y ago

I would already be happy if they supported generics like CLU did in 1975, no need for nothing too fancy.

anth1988 9y ago

This is just another way of saying fuck generics. They really can't see any solvable problems after years of people asking for generics?

slantedview 9y ago

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

43224gg252 9y ago
Then why don't you come up with a legitimate use case?
- treehau5 9y ago
  I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed them, and once was because a library forced me to.
  - slantedview 9y ago
    > Everyone wants generics, no one knows why This is such a troll'ish statement, but I'll respond anyways because maybe you actually are just that uninformed. Without generics any number of libraries that utilize generic function blocks - Func [1] in C#, Callable [2] in Java, etc., and do things like return the function's type parameter as a method result, would not be possible. This is exceedingly common, at least in libraries. If you want to know how common, let me refer you to my friend http://google.com http://google.com. Just because something isn't valuable to you, personally, doesn't mean it's not valuable. As in all aspects of life, not everyone is you. 1. https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110).... 2. https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Callable.html https://docs.oracle.com/javase/7/docs/api/java/util/concurre...
    - deleted 9y ago

kernelbandwidth 9y ago

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the result is my Rust code uses those features extensively and the presence of those features greatly influences the designs. Similarly, when I write Java, I design with inheritance in mind. I would have trouble showing real world use cases for inheritance in my Rust code, because Rust doesn't have inheritance and so the designs don't use inheritance-based patterns. Essentially, how does one provide real world evidence for the utility of something that's only hypothetical? You can't write working programs in hypothetical Go 2-with-generics, so examples are always going to be hypothetical or drawn from other languages where those tools do exist.

erikpukinskis 9y ago
This suggests that both generics and inheritance are unnecessary.
- kccqzy 9y ago
  It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.
  - XorNot 9y ago
    Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them? On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project velocity because when we need to prototype a new requirement, the push back has been paraphrasing "oh, could you not do that in <core product> and handle it somewhere else?" - so we end up with a bunch of shell scripts cobbled together to do so.

vec 9y ago

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn<T>` instead of half a dozen variations on `sql.NullWhatever`) * 99% of functions that accept or return `interface{}` I appreciate that they seem open to the idea for v2, but "the use case isn't clear" is absurdly out of touch with the community. Using `interface{}` to temporarily escape the type system and copy/pasting functions just to adjust the signature a bit were among the first go idioms I learned, and they both exist solely to work around the lack of generics.

zemo 9y ago
> I'm not even a Go developer > Using `interface{}` to temporarily escape the type system tbh if you program Go correctly, you use interface{} pretty rarely.
- camus2 9y ago
  > tbh if you program Go correctly, you use interface{} pretty rarely. It's a bit like saying "if you program C correctly, you use (void *) pretty rarely.". that's not the case, Go maintainers themselves keep on adding API with interface {} everywhere. Are you saying they are not programming Go correctly?
spyspy 9y ago
It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.
- rbehrends 9y ago
  The same argument applies, mutatis mutandis, to imperative iteration constructs such as range.

hota_mazi 9y ago

That's a charitable way to look at the comment. My more cynical reaction is that someone who doesn't understand the benefit of generics or can't even come up with examples where generics are superior to their alternative should not be allowed anywhere near a language design discussion.

kccqzy 9y ago

Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464

kccqzy 9y ago
It really reminds me of early C macros where people use the ## operator to synthesize monomorphized versions.
- fanf2 9y ago
  The ## operator is an ANSI C feature, so not really "early". In pre-ANSI preprocessors you had to abuse the lexer to paste tokens, e.g. by relying on // being deleted - nowadays comments are replaced by space.
stefantalpalaru 9y ago
> Generics in Go: https://twitter.com/snoyberg/status/882255351382462464 https://twitter.com/snoyberg/status/882255351382462464 Generics and Go: https://github.com/stefantalpalaru/golib-nim https://github.com/stefantalpalaru/golib-nim
zyxzkz 9y ago
That's an awesome trick, using angle brackets that aren't angle brackets!