13 ms·

Notes on the Go2 Generics Draft

148 points by ainar-g 8y ago

hugofirth 8y ago
The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain a lot less code; something which has been repeatedly demonstrated to reduce the incidence of bugs. Personally, I am encouraged that the Go team is flexible enough to change their position. That gives me more confidence in the future of the language, not less.
- laumars 8y ago
  I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "haters" (and I hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers) didn't think the slow and methodical approach was good enough. Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently. And frankly I get a little fed up with all the psuedo-religious zealotry some have towards programming languages. It's nuts. Yet that's exactly how many of the language-specific topics end up on HN and why many on here could be forgiven for not realising that the Go team have always been open minded about changing Go; they've just been stubborn about the timelines of such changes.
  - jimmy1 8y ago
    > Sometimes it feels like those who are the loudest critics of Go aren't even Go developers I have been writing Go exclusively for almost 3 years, (I still maintain some legacy J2EE applications, and live in a Java/C# town) -- this has been true anecdotally 99% of the time. There's the one-off who actually does use go regularly. Then again, I witness this same phenomena in the JS framework battles, even within my own company. Vue vs React, where neither of them have ever used each others and built an actual production application to evaluate it. This is just the editor wars over again.
  - viraptor 8y ago
    > critics of Go aren't even Go developers This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released. If only people continuing to use X could criticise X, we wouldn't get much progress.
    - skywhopper 8y ago
      Dependency management was always my pain point, but that has suddenly gotten crazy better with Go 1.11, for what it’s worth.
    - SmirkingRevenge 8y ago
      Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.
      - viraptor 8y ago
        It part of the death by papercuts for me. Sure, it's trivial, but it's the only language that requires it and I can't see any benefit of it. When working with multiple projects, it can lead to weird errors until you remember to change it too. It's like getting a house where you have to use 2 separate switches to turn each light on/off. Is it a big deal? No. It's just weird and annoying, without an obvious benefit.
      - atombender 8y ago
        The complaint about GOPATH is not that it's an environment variable. It's that it enforces a specific directory structure that does not match how most people organize their code trees. Instead of a project being in a folder called, say, "foo", you end up with something like $HOME/go/src/github.com/bar/foo. Then, when you install your project's dependencies, they get commingled into this structure. If you do "ls $HOME/go/src", you'll see a ton of stuff polluting your tree, all of which are arguably build artifacts, not primary sources. Very few people manage their codebases like this. At best, you put all your dependencies under a subfolder somewhere so that there's no confusion. Go 1.11 does away with GOPATH for your project, and relegates all the dependencies to $GOPATH/pkg/mod. We are now using this new module mode, and it's a breath of fresh air compared to the previous system. This way, Go feels a bit more modern and much less gnarly.
  - wwweston 8y ago
    > Sometimes it feels like those who are the loudest critics of Go aren't even Go developers Perhaps unsurprisingly, those who didn't like what they saw when taking a look at Go might well have chosen to work in other languages. This might be a basis on which to prioritize criticism -- certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism. And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed"). I don't begrudge anyone who likes it their happiness using it. I know people who really do like it. But I know people who gave it a fair shot didn't like it. Mine was 9 months of part-time work on a project before I settled into the conclusion that most of MJD's faint praise of Java (https://blog.plover.com/prog/Java.html https://blog.plover.com/prog/Java.html ) plus a few extra downsides applied to Go. Including, yes, the arguably generic-shaped hole. I also don't begrudge the stewards of the language their own solution to that problem or their own timeline for it. Presumably a similarly generous spirit should apply to complaints continuing to register. If the pothole is still in the road, it isn't surprising that observations about it continue to roll in even after plans to develop plans to fix it may have been announced.
    - laumars 8y ago
      > This might be a basis on which to prioritize criticism Maybe if the language was unsuccessful then yes. But given the popularity in f Go it's fair to say the concerns of its existing user base should take precedence over those that may not use the language regardless. > certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism. But as this topic has demonstrated, those concerns haven't been disqualified out if hand either. > And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed"). I disagree that happens. In my first post I made the arguement about language stability (not breaking things). Others have made the arguement of simplicity and/or readability as well. I think the real issue is some people don't consider those good enough reasons so dismiss the counterarguments out if hand. Which is obviously an opinion you're entitled to but you have to remember that it's the stability and simplicity that has made Go popular in the first place so those points actually do matter to a great many of us. The thing is, there is already C#, Java, Rust, C++, and a great many other languages out there that have rich ecosystems and expressive semantics, Go has gone in a different direction by being a boring language. This direction clearly divides people though.
  - coldtea 8y ago
    >I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigms from other languages, and always giving the impression to many people that they were just paying lip service to the idea that they are OK with eventually adding Generics, or stalling for time. The fact that it took 10 years for this to finally come as a concrete suggestion (and not even with a final delivery date or official roadmap yet), means that they were indeed stalling for time. >Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently. This tired argument has been said again and again. Many seasoned go developers have spoken in favor of generics over the years. And this features was #1 in Go's own developers poll year after year. Besides, it's not like non-users of a language are automatically wrong. If anything, they could be the ones seeing its faults more objectively (e.g. people calling out Java world's obsession with overusing patterns).
    - throwaway34241 8y ago
      It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust... Also I see stuff like they should just use "perfectly fine existing paradigms from other languages" on HN all the time. But from the very beginning they said that Java-style generics were undesirable (due to overhead) and C++/Rust style were also undesirable due to code size. In the end, the proposal does not choose either system and tries to enable the compiler to make trade-offs in between. It seems most inspired by CLU and a proposed future C++ feature... I genuinely don't understand why HN views this as an easy thing to just copy in, unless they view the design goals as unnecessary to begin with... I definitely think it will be convenient to have type safety for collections that are not lists or hashmaps/sets. I also think it's convenient to have multiple return values and slices (so every list api accepts sub-lists without copying). Overall, I didn't find Go to be tremendously less convenient than Java or C#... I'm kind of curious what kind of software HN is working on, where Go is so much worse than the alternatives.
  - cyphar 8y ago
    > hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bitter taste in my mouth. Not to mention that Go was sold as a systems programming language, but my last 5 years of experience with the language (developing container runtimes -- which are the most canonical example of systems program you can come up with these days) tell me otherwise.
    - laumars 8y ago
      Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application. However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.
      - cyphar 8y ago
        From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment). The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).
  - bitwize 8y ago
    The Go team should have considered generics for Go 1.0 during the 0.x phase. It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like dependent and higher-kinded types are a bonus. We've also done enough computer science to know there are much better ways to relieve the programmer of the burden of doing all memory/resource management explicitly than a tracing GC. So using a tracing GC in an ostensible systems programming language was another huge boner. Go 1.x was a cascade of bad decisions. It's like Java was in 1995: a language with training wheels that had to change directions entirely when real programmers started using it to build real applications.
    - sethammons 8y ago
      > No exceptions Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.
      - pjmlp 8y ago
        How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.
        giovannibajo1 8y ago
        There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart. I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.
        xfer 8y ago
        Go is also similar to languages like limbo/newsqueak. None of those are popular(many might not have even heard of them). So part of success definitely goes to being successfully marketed as a google product.
  - deleted 8y ago
    [deleted]
- sagichmal 8y ago
  > they are all predicated on the idea that generics are > somehow hard to grok or use? No, rather that the Go contracts proposal specifically is "too nuanced".
RcouF1uZ4gsC 8y ago
Yet another language tries to bolt on generics after the fact and finds that doing so results in awkwardness. Note to language designers: if you are creating a general purpose language, you will eventually need to add generics. You can either do it right at the beginning, or else you have to bolt it on at the end. Rust gets kudos in this regard for having well designed generics from the beginning.
- Filligree 8y ago
  Rust has parametric polymorphism, not generics, and doesn't have subclasses. This makes it not quite the same thing.
  - dbaupp 8y ago
    Rust does have generics. There's little value in constructing a distinction between "templates", "generics" and "parametric polymorphism", at least not for the parent comment, which was likely intended to mean "Rust has a well designed system for working with 'unknown' types". (Also, maybe you could be specific about what you think the difference is.) Go also doesn't have subclasses, so that doesn't seem relevant.
    - mcguire 8y ago
      They're the same thing: "Generics" is a term from software engineering, describing how the concept is typically used. "Parametric polymorphism" is a description from a type theoretic standpoint. "Templates" are an implementation strategy.
      - dbaupp 8y ago
        I understand what these words mean... At least, I understand the variety of meanings they have: they're not always used to mean the same thing. For instance, people will rightly say that Java doesn't strictly have parametric polymorphism because of dynamic type casts, but they will say it has generics. Other people might draw a distinction between generics and templates, with the former being constrained (with type classes or similar) and the latter being macro-like. However, I don't think these are actually particularly relevant to the original comment (and, I really think that Rust probably satisfies "generics" more than "parametric polymorphism", because one can also do generic casts).
scoom 8y ago
Its wonderful how much Go wants everyone to repeatedly develop container data structures. That way everyone gets their own artisanal bugs.
- coldtea 8y ago
  Well, that makes sense, coming from some of the people that gave us C.
Animats 8y ago
That's elaborate. More elaborate than expected for Go. I was expecting something more like explicit parameterized types. Go already has those - maps and channels are parameterized types. You just can't define new parameterized types. Extending Go to allow those would be a smaller step. That doesn't get you overloaded functions, though. The designers of this wanted the ability to define a new function F(T x) which works for any T upon which a known list of functions can be applied. Then they wanted that to work for separate compilation. So there's all that "contract" stuff to carry the info about what F needs from T. Seems clunky. It violates the rule "You should never have to tell the computer something it already knows." It's clear how the constraints they set upon themselves lead there, but it's still clunky. This design does not support template metaprogramming or any other form of compile-time programming. Whew! That's a relief. "We expect that most people will not write generic code themselves, but many people are likely to write packages that use generic code written by others." In other words, maybe it is a little too complicated.
- cbolton 8y ago
  It violates the rule "You should never have to tell the computer something it already knows." Not really: the contract is an explicit list of requirements with API compatibility guarantees for future versions. The computer cannot guess that from the current implementation.
nemo1618 8y ago
I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restricted to a handful of built-in types, but rather should support any type implementing an Iterator interface. But Go was not designed to be perfectly consistent or to enable high-order abstractions. It just aims to be productive at scale, and that often means restricting the programmer. Go tries to be non-magical, and sadly that can take much of the whimsy out of programming. You can't chain together operators in point-free style, or add a property to every 'Object', or directly increment a string, or anything like that. In other words, it's a terrible language for code golfing. But that sort of code has no place in a production environment anyway. It's "clever" code that gives the programmer a little dopamine hit when he writes it, and his co-workers a headache three months later. Those are misaligned incentives. So I worry about generics because they let you abstract with wild abandon. They let you inject a little magic. And I fear that programmers will be seduced by their love of magic, and I'll be the one who ends up paying the price.
- hyeomans 8y ago
  This. Worked with large C# code bases that were full of leaky abstractions using generics. Programmers thought of ever edge case, until you found that edge case that wasn’t covered in the long chain of inheritance of generics. Point being, I agree with you, I know Go doesn’t have inheritance like C# but I’m pretty sure we, as a community, we’ll find a way to complicate everything Go related.
- hcs 8y ago
  Concur, I scratch the golfing itch with Zachtronics games.
- glangdale 8y ago
  I think this argument needs to be treated with caution. I think it's possible to write bad code on top of almost any mechanism. Certainly I've seen my share of bizarre C++ template shenanigans (bad) but I've also been able to reuse other people's really well written container classes rather than roll my own, all with strong type safety (good). Everyone will make their own decisions about generics. Personally I find the risk of "bad generics magic" to be more tolerable than "endless shitty workarounds for not having generics".
Exuma 8y ago
Can someone explain in terms to someone who hasn't really used a static typed language what "generics" are? I've only used javascript and ruby.
- dunpeal 8y ago
  In a static language, functions, classes, and types are often parametrized by other types. For example, with a function: imagine you wrote a `sum(array)` function. In Ruby that's not a problem, because array can contain any types, as long as they support the + operator (aka duck typing). Any function can also return any type of object. In a static language, however, an array that holds floats has a different type than an array that holds integers or an array that holds strings. The return value of the function sum() will also be different, depending on the type of the array, because if it's an array of floats, the sum will be a float. So generics allow you to sort of implement duck-typing in static language: T sum(array<T>) // Pseudocode Now the sum function will take an array of any type T, and return a result of the same type T. Similar idea for classes and other types. The classic example is a container. A linked-list in Ruby can contain any type or mixture a types, since the language is fully dynamic. However, in a static language, a linked-list of strings has a different type than a linked-list of ints. So you write something like (pseudocode): class List<T> { T head_val() { return head.val; } } Now you write the List<T> class once, and use it for any type T, so it's DRY when you may have any number of types T that your program stores in a list.
  - Exuma 8y ago
    Awesome, so this makes sense. So I guess people are against it because they like the explicit simple nature of Go rather than some sort of abstraction magic?
    - dunpeal 8y ago
      I can't speak for all of them, but generics do tend to add a bunch of rules to a language, and make it more complex than before.
- jniedrauer 8y ago
bww 8y ago
I’m a fellow generics pessimist. Having come to Go from Java some 6 years ago I initially found the lack of generics a curious, sometimes frustrating omission. After years of using Go daily and reading a long succession of posts on the go-nuts mailing list wherein Rob Pike, et al, repeatedly and staunchly defended the lack of generics as necessary – even beneficial – in the pursuit of designing a small, readable, coherent language, I’ve since come to believe that decision was entirely correct. Perhaps nobody technically promised there would never be generics in Go’s future, but it’s undeniable that they run contrary to those stated design goals. As currently proposed, they will add considerable complexity to the language in exchange for questionable benefit. I’m not sure the world needs another kitchen-sink language that eschews clarity for the unrestrained addition of features. If you want that, there are already plenty of options for you.
- everybodyknows 8y ago
  Speaking of Rob Pike, don't see his name on any of the Go2 proposals. His lucidity and circumspection are sorely missed. Could we be witnessing the psychological phenomenon of a "second-system effect" -- as described in The Mythical Man-Month -- writ very large?
  - ainar-g 8y ago
    The only person from the original three creators who still actively takes part in the language's evolution seems to be Robert Griesemer. Ken Thompson is retired, and Rob Pike seems to have moved to other projects (Upspin?). Robert Griesemer is still active, but mostly "debugging" the language specification. The impression I get is that Russ Cox is pretty much the Chief Designer right now (pardon the Sergey Korolyov reference). The original three authors have said that they would not add a feature to the language if one of them opposed it, which is how they kept it simple. I wonder if rsc has anyone to say "no" to him.
zmanian 8y ago
It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generics/generics.go https://github.com/google/gvisor/blob/master/tools/go_generi...
- dnomad 8y ago
  Exactly. Like all ideological arguments it completely ignores actual real-world evidence. Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling. My (anecdotal) experience and speculation suggests that you'd see massive reduction in complexity and lines of code (especially when you consider code-gen). But then this is part of a larger problem of the community which isn't motivated by evidence or basic pragmatism but rather strict adherence to a philosophy.
  - frankietwenty9 8y ago
    Changing the language specifically requires experience reports. If that's not real world evidence i'm not sure what is. The problem with the wider go community is they are usually not driven by evidence, but adherence to a philosophy. eg, its not possible to write large programs without generics.
  - baby 8y ago
    > Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling And also how most codebases would be worsen.
- cshenton 8y ago
  It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.
jahaja 8y ago
I'm a bit sad about the lack of acceptance for pluralism in widely used languages. The effort to get Go in line with other languages just seem so disproportional.
- jy3 8y ago
  Reading HN, it feels like some people just want every language to have the same features and have them implemented the same way. Sad indeed.
  - bodas 8y ago
    Go is a tool, it's not a religion. People are allowed to criticise it, and they don't have to temper their criticism just because the Go team or Go users have a different opinion. Go is made by Google it's not like it's some kid's school project.
stewbrew 8y ago
Every time I read a discussion about generics in Go, I remember discussions on the Small/SmartEiffel list where people argued that Eiffel doesn't need this or that because it can be emulated with a feature already available in the language. Well, Eiffel is history now.
realrocker 8y ago
I have written about 10+ medium and big projects in Go for production over last 6 years. They were written mostly for CI/CD, APIs, cron jobs and various pipelines in e-commerce and consumer electronics domains. Have personally never needed generics or have felt that I can improve the code by using generics. I also have quite a bit of Java experience so I do know why you would need generics, but it just never came up in Go. Maybe my opinion will change with the new proposal getting implemented, but at this point I don't see how.
atsjie 8y ago
The proposal reads like an attempt to add generics to a language that was not conceived to include it in the first place. It looks complex.
- vorg 8y ago
  I agree. The real problem is they're trying to add generics to Go and make Go 2 backwards-compatible with Go 1. Doing both generates the complexity, just like with Java 5. Generics in a language are good, but Go will cross the line from simple to bloated as soon as these generics are added. To remain a simple language with generics, Go 2 would need to give up backwards compatibility with Go 1, something which the suits at Google would veto if any techies there actually tried it.

148 points by ainar-g 8y ago

The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain a lot less code; something which has been repeatedly demonstrated to reduce the incidence of bugs. Personally, I am encouraged that the Go team is flexible enough to change their position. That gives me more confidence in the future of the language, not less.

laumars 8y ago
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "haters" (and I hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers) didn't think the slow and methodical approach was good enough. Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently. And frankly I get a little fed up with all the psuedo-religious zealotry some have towards programming languages. It's nuts. Yet that's exactly how many of the language-specific topics end up on HN and why many on here could be forgiven for not realising that the Go team have always been open minded about changing Go; they've just been stubborn about the timelines of such changes.
- jimmy1 8y ago
  > Sometimes it feels like those who are the loudest critics of Go aren't even Go developers I have been writing Go exclusively for almost 3 years, (I still maintain some legacy J2EE applications, and live in a Java/C# town) -- this has been true anecdotally 99% of the time. There's the one-off who actually does use go regularly. Then again, I witness this same phenomena in the JS framework battles, even within my own company. Vue vs React, where neither of them have ever used each others and built an actual production application to evaluate it. This is just the editor wars over again.
- viraptor 8y ago
  > critics of Go aren't even Go developers This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released. If only people continuing to use X could criticise X, we wouldn't get much progress.
  - skywhopper 8y ago
    Dependency management was always my pain point, but that has suddenly gotten crazy better with Go 1.11, for what it’s worth.
  - SmirkingRevenge 8y ago
    Complaints about gopath always feel like such a nitpick to me. Environment variables are trivial. Few Languages are as simple as Go, when it comes to development environments.
    - viraptor 8y ago
      It part of the death by papercuts for me. Sure, it's trivial, but it's the only language that requires it and I can't see any benefit of it. When working with multiple projects, it can lead to weird errors until you remember to change it too. It's like getting a house where you have to use 2 separate switches to turn each light on/off. Is it a big deal? No. It's just weird and annoying, without an obvious benefit.
    - atombender 8y ago
      The complaint about GOPATH is not that it's an environment variable. It's that it enforces a specific directory structure that does not match how most people organize their code trees. Instead of a project being in a folder called, say, "foo", you end up with something like $HOME/go/src/github.com/bar/foo. Then, when you install your project's dependencies, they get commingled into this structure. If you do "ls $HOME/go/src", you'll see a ton of stuff polluting your tree, all of which are arguably build artifacts, not primary sources. Very few people manage their codebases like this. At best, you put all your dependencies under a subfolder somewhere so that there's no confusion. Go 1.11 does away with GOPATH for your project, and relegates all the dependencies to $GOPATH/pkg/mod. We are now using this new module mode, and it's a breath of fresh air compared to the previous system. This way, Go feels a bit more modern and much less gnarly.
- wwweston 8y ago
  > Sometimes it feels like those who are the loudest critics of Go aren't even Go developers Perhaps unsurprisingly, those who didn't like what they saw when taking a look at Go might well have chosen to work in other languages. This might be a basis on which to prioritize criticism -- certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism. And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed"). I don't begrudge anyone who likes it their happiness using it. I know people who really do like it. But I know people who gave it a fair shot didn't like it. Mine was 9 months of part-time work on a project before I settled into the conclusion that most of MJD's faint praise of Java (https://blog.plover.com/prog/Java.html https://blog.plover.com/prog/Java.html ) plus a few extra downsides applied to Go. Including, yes, the arguably generic-shaped hole. I also don't begrudge the stewards of the language their own solution to that problem or their own timeline for it. Presumably a similarly generous spirit should apply to complaints continuing to register. If the pothole is still in the road, it isn't surprising that observations about it continue to roll in even after plans to develop plans to fix it may have been announced.
  - laumars 8y ago
    > This might be a basis on which to prioritize criticism Maybe if the language was unsuccessful then yes. But given the popularity in f Go it's fair to say the concerns of its existing user base should take precedence over those that may not use the language regardless. > certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism. But as this topic has demonstrated, those concerns haven't been disqualified out if hand either. > And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed"). I disagree that happens. In my first post I made the arguement about language stability (not breaking things). Others have made the arguement of simplicity and/or readability as well. I think the real issue is some people don't consider those good enough reasons so dismiss the counterarguments out if hand. Which is obviously an opinion you're entitled to but you have to remember that it's the stability and simplicity that has made Go popular in the first place so those points actually do matter to a great many of us. The thing is, there is already C#, Java, Rust, C++, and a great many other languages out there that have rich ecosystems and expressive semantics, Go has gone in a different direction by being a boring language. This direction clearly divides people though.
- coldtea 8y ago
  >I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigms from other languages, and always giving the impression to many people that they were just paying lip service to the idea that they are OK with eventually adding Generics, or stalling for time. The fact that it took 10 years for this to finally come as a concrete suggestion (and not even with a final delivery date or official roadmap yet), means that they were indeed stalling for time. >Sometimes it feels like those who are the loudest critics of Go aren't even Go developers and instead just like to shout about how amazing their preferences are because it does xyz differently. This tired argument has been said again and again. Many seasoned go developers have spoken in favor of generics over the years. And this features was #1 in Go's own developers poll year after year. Besides, it's not like non-users of a language are automatically wrong. If anything, they could be the ones seeing its faults more objectively (e.g. people calling out Java world's obsession with overusing patterns).
  - throwaway34241 8y ago
    It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust... Also I see stuff like they should just use "perfectly fine existing paradigms from other languages" on HN all the time. But from the very beginning they said that Java-style generics were undesirable (due to overhead) and C++/Rust style were also undesirable due to code size. In the end, the proposal does not choose either system and tries to enable the compiler to make trade-offs in between. It seems most inspired by CLU and a proposed future C++ feature... I genuinely don't understand why HN views this as an easy thing to just copy in, unless they view the design goals as unnecessary to begin with... I definitely think it will be convenient to have type safety for collections that are not lists or hashmaps/sets. I also think it's convenient to have multiple return values and slices (so every list api accepts sub-lists without copying). Overall, I didn't find Go to be tremendously less convenient than Java or C#... I'm kind of curious what kind of software HN is working on, where Go is so much worse than the alternatives.
- cyphar 8y ago
  > hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bitter taste in my mouth. Not to mention that Go was sold as a systems programming language, but my last 5 years of experience with the language (developing container runtimes -- which are the most canonical example of systems program you can come up with these days) tell me otherwise.
  - laumars 8y ago
    Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application. However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.
    - cyphar 8y ago
      From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment). The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).
- bitwize 8y ago
  The Go team should have considered generics for Go 1.0 during the 0.x phase. It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like dependent and higher-kinded types are a bonus. We've also done enough computer science to know there are much better ways to relieve the programmer of the burden of doing all memory/resource management explicitly than a tracing GC. So using a tracing GC in an ostensible systems programming language was another huge boner. Go 1.x was a cascade of bad decisions. It's like Java was in 1995: a language with training wheels that had to change directions entirely when real programmers started using it to build real applications.
  - sethammons 8y ago
    > No exceptions Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.
    - pjmlp 8y ago
      How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.
      - giovannibajo1 8y ago
        There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart. I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.
        xfer 8y ago
        Go is also similar to languages like limbo/newsqueak. None of those are popular(many might not have even heard of them). So part of success definitely goes to being successfully marketed as a google product.
- deleted 8y ago
  [deleted]
sagichmal 8y ago
> they are all predicated on the idea that generics are > somehow hard to grok or use? No, rather that the Go contracts proposal specifically is "too nuanced".

RcouF1uZ4gsC 8y ago

Yet another language tries to bolt on generics after the fact and finds that doing so results in awkwardness. Note to language designers: if you are creating a general purpose language, you will eventually need to add generics. You can either do it right at the beginning, or else you have to bolt it on at the end. Rust gets kudos in this regard for having well designed generics from the beginning.

Filligree 8y ago
Rust has parametric polymorphism, not generics, and doesn't have subclasses. This makes it not quite the same thing.
- dbaupp 8y ago
  Rust does have generics. There's little value in constructing a distinction between "templates", "generics" and "parametric polymorphism", at least not for the parent comment, which was likely intended to mean "Rust has a well designed system for working with 'unknown' types". (Also, maybe you could be specific about what you think the difference is.) Go also doesn't have subclasses, so that doesn't seem relevant.
  - mcguire 8y ago
    They're the same thing: "Generics" is a term from software engineering, describing how the concept is typically used. "Parametric polymorphism" is a description from a type theoretic standpoint. "Templates" are an implementation strategy.
    - dbaupp 8y ago
      I understand what these words mean... At least, I understand the variety of meanings they have: they're not always used to mean the same thing. For instance, people will rightly say that Java doesn't strictly have parametric polymorphism because of dynamic type casts, but they will say it has generics. Other people might draw a distinction between generics and templates, with the former being constrained (with type classes or similar) and the latter being macro-like. However, I don't think these are actually particularly relevant to the original comment (and, I really think that Rust probably satisfies "generics" more than "parametric polymorphism", because one can also do generic casts).

scoom 8y ago

Its wonderful how much Go wants everyone to repeatedly develop container data structures. That way everyone gets their own artisanal bugs.

coldtea 8y ago
Well, that makes sense, coming from some of the people that gave us C.

Animats 8y ago

That's elaborate. More elaborate than expected for Go. I was expecting something more like explicit parameterized types. Go already has those - maps and channels are parameterized types. You just can't define new parameterized types. Extending Go to allow those would be a smaller step. That doesn't get you overloaded functions, though. The designers of this wanted the ability to define a new function F(T x) which works for any T upon which a known list of functions can be applied. Then they wanted that to work for separate compilation. So there's all that "contract" stuff to carry the info about what F needs from T. Seems clunky. It violates the rule "You should never have to tell the computer something it already knows." It's clear how the constraints they set upon themselves lead there, but it's still clunky. This design does not support template metaprogramming or any other form of compile-time programming. Whew! That's a relief. "We expect that most people will not write generic code themselves, but many people are likely to write packages that use generic code written by others." In other words, maybe it is a little too complicated.

cbolton 8y ago
It violates the rule "You should never have to tell the computer something it already knows." Not really: the contract is an explicit list of requirements with API compatibility guarantees for future versions. The computer cannot guess that from the current implementation.

nemo1618 8y ago

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restricted to a handful of built-in types, but rather should support any type implementing an Iterator interface. But Go was not designed to be perfectly consistent or to enable high-order abstractions. It just aims to be productive at scale, and that often means restricting the programmer. Go tries to be non-magical, and sadly that can take much of the whimsy out of programming. You can't chain together operators in point-free style, or add a property to every 'Object', or directly increment a string, or anything like that. In other words, it's a terrible language for code golfing. But that sort of code has no place in a production environment anyway. It's "clever" code that gives the programmer a little dopamine hit when he writes it, and his co-workers a headache three months later. Those are misaligned incentives. So I worry about generics because they let you abstract with wild abandon. They let you inject a little magic. And I fear that programmers will be seduced by their love of magic, and I'll be the one who ends up paying the price.

hyeomans 8y ago
This. Worked with large C# code bases that were full of leaky abstractions using generics. Programmers thought of ever edge case, until you found that edge case that wasn’t covered in the long chain of inheritance of generics. Point being, I agree with you, I know Go doesn’t have inheritance like C# but I’m pretty sure we, as a community, we’ll find a way to complicate everything Go related.
hcs 8y ago
Concur, I scratch the golfing itch with Zachtronics games.
glangdale 8y ago
I think this argument needs to be treated with caution. I think it's possible to write bad code on top of almost any mechanism. Certainly I've seen my share of bizarre C++ template shenanigans (bad) but I've also been able to reuse other people's really well written container classes rather than roll my own, all with strong type safety (good). Everyone will make their own decisions about generics. Personally I find the risk of "bad generics magic" to be more tolerable than "endless shitty workarounds for not having generics".

Exuma 8y ago

Can someone explain in terms to someone who hasn't really used a static typed language what "generics" are? I've only used javascript and ruby.

dunpeal 8y ago
In a static language, functions, classes, and types are often parametrized by other types. For example, with a function: imagine you wrote a `sum(array)` function. In Ruby that's not a problem, because array can contain any types, as long as they support the + operator (aka duck typing). Any function can also return any type of object. In a static language, however, an array that holds floats has a different type than an array that holds integers or an array that holds strings. The return value of the function sum() will also be different, depending on the type of the array, because if it's an array of floats, the sum will be a float. So generics allow you to sort of implement duck-typing in static language: T sum(array<T>) // Pseudocode Now the sum function will take an array of any type T, and return a result of the same type T. Similar idea for classes and other types. The classic example is a container. A linked-list in Ruby can contain any type or mixture a types, since the language is fully dynamic. However, in a static language, a linked-list of strings has a different type than a linked-list of ints. So you write something like (pseudocode): class List<T> { T head_val() { return head.val; } } Now you write the List<T> class once, and use it for any type T, so it's DRY when you may have any number of types T that your program stores in a list.
- Exuma 8y ago
  Awesome, so this makes sense. So I guess people are against it because they like the explicit simple nature of Go rather than some sort of abstraction magic?
  - dunpeal 8y ago
    I can't speak for all of them, but generics do tend to add a bunch of rules to a language, and make it more complex than before.
jniedrauer 8y ago

bww 8y ago

I’m a fellow generics pessimist. Having come to Go from Java some 6 years ago I initially found the lack of generics a curious, sometimes frustrating omission. After years of using Go daily and reading a long succession of posts on the go-nuts mailing list wherein Rob Pike, et al, repeatedly and staunchly defended the lack of generics as necessary – even beneficial – in the pursuit of designing a small, readable, coherent language, I’ve since come to believe that decision was entirely correct. Perhaps nobody technically promised there would never be generics in Go’s future, but it’s undeniable that they run contrary to those stated design goals. As currently proposed, they will add considerable complexity to the language in exchange for questionable benefit. I’m not sure the world needs another kitchen-sink language that eschews clarity for the unrestrained addition of features. If you want that, there are already plenty of options for you.

everybodyknows 8y ago
Speaking of Rob Pike, don't see his name on any of the Go2 proposals. His lucidity and circumspection are sorely missed. Could we be witnessing the psychological phenomenon of a "second-system effect" -- as described in The Mythical Man-Month -- writ very large?
- ainar-g 8y ago
  The only person from the original three creators who still actively takes part in the language's evolution seems to be Robert Griesemer. Ken Thompson is retired, and Rob Pike seems to have moved to other projects (Upspin?). Robert Griesemer is still active, but mostly "debugging" the language specification. The impression I get is that Russ Cox is pretty much the Chief Designer right now (pardon the Sergey Korolyov reference). The original three authors have said that they would not add a feature to the language if one of them opposed it, which is how they kept it simple. I wonder if rsc has anyone to say "no" to him.

zmanian 8y ago

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generics/generics.go https://github.com/google/gvisor/blob/master/tools/go_generi...

dnomad 8y ago
Exactly. Like all ideological arguments it completely ignores actual real-world evidence. Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling. My (anecdotal) experience and speculation suggests that you'd see massive reduction in complexity and lines of code (especially when you consider code-gen). But then this is part of a larger problem of the community which isn't motivated by evidence or basic pragmatism but rather strict adherence to a philosophy.
- frankietwenty9 8y ago
  Changing the language specifically requires experience reports. If that's not real world evidence i'm not sure what is. The problem with the wider go community is they are usually not driven by evidence, but adherence to a philosophy. eg, its not possible to write large programs without generics.
- baby 8y ago
  > Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling And also how most codebases would be worsen.
cshenton 8y ago
It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.

jahaja 8y ago

I'm a bit sad about the lack of acceptance for pluralism in widely used languages. The effort to get Go in line with other languages just seem so disproportional.

jy3 8y ago
Reading HN, it feels like some people just want every language to have the same features and have them implemented the same way. Sad indeed.
- bodas 8y ago
  Go is a tool, it's not a religion. People are allowed to criticise it, and they don't have to temper their criticism just because the Go team or Go users have a different opinion. Go is made by Google it's not like it's some kid's school project.

stewbrew 8y ago

Every time I read a discussion about generics in Go, I remember discussions on the Small/SmartEiffel list where people argued that Eiffel doesn't need this or that because it can be emulated with a feature already available in the language. Well, Eiffel is history now.

realrocker 8y ago

I have written about 10+ medium and big projects in Go for production over last 6 years. They were written mostly for CI/CD, APIs, cron jobs and various pipelines in e-commerce and consumer electronics domains. Have personally never needed generics or have felt that I can improve the code by using generics. I also have quite a bit of Java experience so I do know why you would need generics, but it just never came up in Go. Maybe my opinion will change with the new proposal getting implemented, but at this point I don't see how.

atsjie 8y ago

The proposal reads like an attempt to add generics to a language that was not conceived to include it in the first place. It looks complex.

vorg 8y ago
I agree. The real problem is they're trying to add generics to Go and make Go 2 backwards-compatible with Go 1. Doing both generates the complexity, just like with Java 5. Generics in a language are good, but Go will cross the line from simple to bloated as soon as these generics are added. To remain a simple language with generics, Go 2 would need to give up backwards compatibility with Go 1, something which the suits at Google would veto if any techies there actually tried it.