4 ms·

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before re

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decades. It was clearly the result of a lot of NIH syndrome. It was built by Plan 9 guys to solve their problems on their preferred platform. For their purpose, I am sure it works just fine and is very comfortable for them. To expect it to be adapted to other kinds of problems and platforms is just wishful thinking. For years, I have been hearing that Go will get generics and that it will be easy to add and use. I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. This made me skeptical that Go with generics would be as good as it could be. Now Go finally has generics and many are not happy. This should not be surprising. This is why I see it as an abusive relationship. That partner you are so fond of is not going to change. Accept that and stay or move on.

klodolph 5y ago
I don’t get the “abusive relationship” metaphor. It just seems like the “abuse” metaphor is an attempt to stir up emotions. Every language has its own weird way of doing things. You decided Go wouldn’t work for you? Ok, I get it. People who stick with Go are in an “abusive relationship”? Seems like an attempt to stir up a flame war more than anything else. I’ve never encountered a language that I’m 100% happy with. It’s always been about cataloguing the tradeoffs. I’ve even designed my own domain-specific languages a few times—languages that are laser-focused on solving a small set of problems that I have. It seemed impossible to design a language that would even solve my narrow set of problems in an ideal way. I was always making tradeoffs, from the syntax to the semantics. I’d make syntax for one thing slightly simpler, and then I’d realize that I introduced some ambiguity, so I can make the parser way more complicated, or I can make the grammar way more complicated, or maybe I try again. Over and over again, “simple” changes in small languages turned out to be diabolically complicated. There are plenty of languages that I’ve personally just stopped working with because I can’t deal, personally, with the design decisions. Java is one. Haskell is one. (And the reason I gave up Haskell is all about finalizers, FFI, and the library ecosystem, it’s not about types or the language itself.) Rust is another, but I check in every once in a while to see if Rust has improved. I’d love to give up on C and C++, but realistically, there are too many existing libraries that I want to work with, and it’s often more fuss working with FFI than to just write C++ in the first place. And just to speak about Go… there’s a small hobby community I’m in. People build their own tools to get things done. There are tools written in Go, and there are people who complain that the tools are written in Go. They think Go is awful, they hate it. But the complainers (in this particular community) don’t seem to be writing any tools themselves. Instead, we keep getting new tools, written in Go. The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later.
- mcculley 5y ago
  It sounds like you enjoy Go. That is great. I am referring to TFA/post which sounds similar to many experiences with Go. Of course all languages have pros and cons. I am referring to the specific situation where people are expecting a modern language and ecosystem heavily influenced by its user community. Go is not such a language. People should have different expectations. > The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later. I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history.
  - klodolph 5y ago
    > I am referring to TFA/post which sounds similar to many experiences with Go. Lots of people have bad experiences with Java, C++, Rust, Python, or JavaScript. I've had bad experiences with all of those languages, as well as bad experiences with Go. I don't think you've managed to articulate what makes Go different. I'm not saying you should use Go. I will say this: it sounds like you have opinions about Go, and I can't tell if you're trying to imply that those opinions are somehow universal or common, or reflect some actual design flaw in Go that you can articulate. "Many are not happy" about Go generics but that's inevitable, IMO. I don't think there's any possible language design decision that won't make many people unhappy. You might as well be asking for pizza toppings that make everyone happy. > I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history. I can understand why you would think that way, but Go seems to me completely different. When I look at Go, I see a ton of small decisions where it seems like (to me) that the Go language designers have taken some fairly sophisticated lessons from history. Things like: - Error handling, - Strings, - Default garbage collector tuning, - Generics, - Dependencies, - Versioning. Just to pick an example... Java's checked exceptions are a good idea, but have some unfortunate consequences when Java is used for larger projects. One of the key problems is that when you handle an error, you don't just need to know what the error is, but where the error came from. Some errors can be handled at a distance and some errors must be handled near their origin. Errors in this second category can be made into checked exceptions in Java--at least, that's the idea--but in practice, it's a bit of a mess. If you pull back from dividing errors into checked / unchecked variants, then you lose the ability for the language to help you distinguish between errors that can be handled locally and errors that can be handled at a distance. IMO, Go's decision to use error returns makes the decision that "local error handling is default", which is a pretty nuanced take on things that I really appreciate. I don't think anyone would have come up with Go's error handling approach without the lessons from Java's error handling approach. Some people hate it. That doesn't mean that it "didn't learn from history".
throwaway894345 5y ago
I would challenge you to rephrase this without the loaded language, not only because loaded language invites a flame war, but also to see if your argument is compelling without assuming outright that the language is bad. I.e., can you make a persuasive argument that the language is bad rather than simply coming up with myriad different ways of implying that you don't like the language (or perhaps even the people who do like the language). I think this is a good way to debate/discuss in general; nothing particular to Go or programming languages (although it may not yield as many upvotes).
- mcculley 5y ago
  I won't edit my post. Maybe I did use bad wording. I will contemplate that. I don't think Go is "bad". The important point to me is the expectation that Go will adapt to its user community. For example, I am not at all surprised that Go has bad abstractions for files under Windows. I would not expect Pike or Thompson to care about Windows. I would not try to make Go work as a cross platform language.
  - throwaway894345 5y ago
    I'm not asking you to edit your post per se, I was giving feedback that your post is (1) flame-y and (2) not very compelling because it leans more on loaded language than it does on reasoned argument (and there are plenty of reasoned arguments to be made against Go, including, for example, the Windows file abstraction argument in your more recent post).
Cthulhu_ 5y ago
> I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. Counterpoints; was the concept of generics a thing before Java implemented it? That is, could they have known? Second, a ton of the Java spec and compilers and stuff is dedicated to generics; would it have been less complicated and voluminous if Java had it from the start? With Go, they took their time to think about generics, just to avoid bloating half the compiler with implementations and workarounds and the like just to support generics, or to not end up with Scala's massive architecture. Their focus remains on a simple language, simple code, and a fast compiler; in many ways it's the antithesis of Scala in that regard. anyway, just some Thoughts I have on the matter.
- halkcyon 5y ago
  > was the concept of generics a thing before Java implemented it? That is, could they have known? You can literally google "X lang feature" and it gives you a date. ML/Ada have had generics since the 70s.

klodolph 5y ago

I don’t get the “abusive relationship” metaphor. It just seems like the “abuse” metaphor is an attempt to stir up emotions. Every language has its own weird way of doing things. You decided Go wouldn’t work for you? Ok, I get it. People who stick with Go are in an “abusive relationship”? Seems like an attempt to stir up a flame war more than anything else. I’ve never encountered a language that I’m 100% happy with. It’s always been about cataloguing the tradeoffs. I’ve even designed my own domain-specific languages a few times—languages that are laser-focused on solving a small set of problems that I have. It seemed impossible to design a language that would even solve my narrow set of problems in an ideal way. I was always making tradeoffs, from the syntax to the semantics. I’d make syntax for one thing slightly simpler, and then I’d realize that I introduced some ambiguity, so I can make the parser way more complicated, or I can make the grammar way more complicated, or maybe I try again. Over and over again, “simple” changes in small languages turned out to be diabolically complicated. There are plenty of languages that I’ve personally just stopped working with because I can’t deal, personally, with the design decisions. Java is one. Haskell is one. (And the reason I gave up Haskell is all about finalizers, FFI, and the library ecosystem, it’s not about types or the language itself.) Rust is another, but I check in every once in a while to see if Rust has improved. I’d love to give up on C and C++, but realistically, there are too many existing libraries that I want to work with, and it’s often more fuss working with FFI than to just write C++ in the first place. And just to speak about Go… there’s a small hobby community I’m in. People build their own tools to get things done. There are tools written in Go, and there are people who complain that the tools are written in Go. They think Go is awful, they hate it. But the complainers (in this particular community) don’t seem to be writing any tools themselves. Instead, we keep getting new tools, written in Go. The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later.

mcculley 5y ago
It sounds like you enjoy Go. That is great. I am referring to TFA/post which sounds similar to many experiences with Go. Of course all languages have pros and cons. I am referring to the specific situation where people are expecting a modern language and ecosystem heavily influenced by its user community. Go is not such a language. People should have different expectations. > The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later. I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history.
- klodolph 5y ago
  > I am referring to TFA/post which sounds similar to many experiences with Go. Lots of people have bad experiences with Java, C++, Rust, Python, or JavaScript. I've had bad experiences with all of those languages, as well as bad experiences with Go. I don't think you've managed to articulate what makes Go different. I'm not saying you should use Go. I will say this: it sounds like you have opinions about Go, and I can't tell if you're trying to imply that those opinions are somehow universal or common, or reflect some actual design flaw in Go that you can articulate. "Many are not happy" about Go generics but that's inevitable, IMO. I don't think there's any possible language design decision that won't make many people unhappy. You might as well be asking for pizza toppings that make everyone happy. > I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history. I can understand why you would think that way, but Go seems to me completely different. When I look at Go, I see a ton of small decisions where it seems like (to me) that the Go language designers have taken some fairly sophisticated lessons from history. Things like: - Error handling, - Strings, - Default garbage collector tuning, - Generics, - Dependencies, - Versioning. Just to pick an example... Java's checked exceptions are a good idea, but have some unfortunate consequences when Java is used for larger projects. One of the key problems is that when you handle an error, you don't just need to know what the error is, but where the error came from. Some errors can be handled at a distance and some errors must be handled near their origin. Errors in this second category can be made into checked exceptions in Java--at least, that's the idea--but in practice, it's a bit of a mess. If you pull back from dividing errors into checked / unchecked variants, then you lose the ability for the language to help you distinguish between errors that can be handled locally and errors that can be handled at a distance. IMO, Go's decision to use error returns makes the decision that "local error handling is default", which is a pretty nuanced take on things that I really appreciate. I don't think anyone would have come up with Go's error handling approach without the lessons from Java's error handling approach. Some people hate it. That doesn't mean that it "didn't learn from history".

throwaway894345 5y ago

I would challenge you to rephrase this without the loaded language, not only because loaded language invites a flame war, but also to see if your argument is compelling without assuming outright that the language is bad. I.e., can you make a persuasive argument that the language is bad rather than simply coming up with myriad different ways of implying that you don't like the language (or perhaps even the people who do like the language). I think this is a good way to debate/discuss in general; nothing particular to Go or programming languages (although it may not yield as many upvotes).

mcculley 5y ago
I won't edit my post. Maybe I did use bad wording. I will contemplate that. I don't think Go is "bad". The important point to me is the expectation that Go will adapt to its user community. For example, I am not at all surprised that Go has bad abstractions for files under Windows. I would not expect Pike or Thompson to care about Windows. I would not try to make Go work as a cross platform language.
- throwaway894345 5y ago
  I'm not asking you to edit your post per se, I was giving feedback that your post is (1) flame-y and (2) not very compelling because it leans more on loaded language than it does on reasoned argument (and there are plenty of reasoned arguments to be made against Go, including, for example, the Windows file abstraction argument in your more recent post).

Cthulhu_ 5y ago

> I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. Counterpoints; was the concept of generics a thing before Java implemented it? That is, could they have known? Second, a ton of the Java spec and compilers and stuff is dedicated to generics; would it have been less complicated and voluminous if Java had it from the start? With Go, they took their time to think about generics, just to avoid bloating half the compiler with implementations and workarounds and the like just to support generics, or to not end up with Scala's massive architecture. Their focus remains on a simple language, simple code, and a fast compiler; in many ways it's the antithesis of Scala in that regard. anyway, just some Thoughts I have on the matter.

halkcyon 5y ago
> was the concept of generics a thing before Java implemented it? That is, could they have known? You can literally google "X lang feature" and it gives you a date. ML/Ada have had generics since the 70s.