5 ms·

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

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".

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".