4 ms·

I believe the author's tone is what is getting you here. They really should have phrased the comment like "I'm really happy with a C# .NET backend because of a

I believe the author's tone is what is getting you here. They really should have phrased the comment like "I'm really happy with a C# .NET backend because of a,b,c. What advantages would Go have over this backend to make it worthwhile for me to investigate?" This would have been a more useful comment. People invest time in their languages so it's easy to subtly inject emotions into comments that come off snarky and unproductive. Then other supporters of the language just defensively click the up arrow. There was a lot of this in the WASM articles where they were saying it will kill off Javascript.

osweiller 11y ago
Even though such a question would be more useful, I'm glad they didn't go that route as it would be dishonest: Too often we see the "why should I learn this?" questions that are really transparent "Why I haven't and won't bother -- my mind is firmly made up -- and here's how I pretend that I'm just being open minded in critiquing it" posts. Many of us are happy in our niche, and learning new things is often a PITA. We're happy with what we do and how we do it, with the tools and things that we're used to. And that's okay. The truth is that the language evolution is something that we can mostly just ignore, and if eventually something is truly dominant for a use case, we can easily adopt it with no real handicap over people who ground with it from the ugly beginnings (and many of those advantages will percolate to other platforms anyways. node.js is just layers and layers of compromises and problems, but it had a profound impact on other platforms, and truly changed the web serving game). And that's okay. But traditionally if someone posts resources for a particular language, it is bad form to engage in language wars, gloating, holier than thou (which the whole scarequote "maybe it isn't `trendy'" sorts of posts really are), etc, in the discussions. They're boring, we've had them literally thousands of times, and they are a distraction from discussing the actual contents of the post. I've noticed this particularly afflicts Go discussions. Python, Rust, D, Swift...all can be discussed rationally and productively. But if Go appears, it seems to be just threatening enough that it draws out people concerned about things they don't know.
- geodel 11y ago
  > I've noticed this particularly afflicts Go discussions. Python, Rust, D, Swift...all can be discussed rationally and productively. But if Go appears, it seems to be just threatening enough that it draws out people concerned about things they don't know. I totally agree with that. Apart from Swift which is by fiat, Go is the only language in top 15 or so which is used for serious work by developers who are not PL enthusiasts/theorists. This is putting serious, though I think unfair, demands on Go developers to justify their choice. So users of languages as diverse Haskell, Elixir, Java, Rust, Scala and many more keep beating Go with their favorite feature of preferred language. Somehow Rust specially stands out as its users/developers seems 100 times more interested in Go related discussions than vice versa. It is similar to politics saying: "You may not be interested in politics but it doesn't means politics is not interested in you"
  - danieldk 11y ago
    It also doesn't help that Go users tend to deny weaknesses in Go. The typical line is 'you don't understand it because you have not used it long enough'. I have written Go intensively and less intensively over the course of last four years. Not surprisingly, most of the criticism are true.
    - geodel 11y ago
      I think criticism is all fine even by non-users. What I do not like is justifying to others who have no stake in project that why I used Go in place of lang of their choice.
    - karmakaze 11y ago
      Having used Go for some time now, and suspect that this attitude is a reflection of 'The Go Authors' and documentation. Although it's described as a systems language, it glosses over many low level details. The 'atomic' package says 'These functions require great care to be used correctly.' In attempting to find out what care is required, I ultimately discovered that the authors couldn't agree on how to express how to define its operation. When used for applications and running into shortcomings, the response is that it's not meant for that. The takeaway is that Go hits a spot between low-level systems programming and applications.

osweiller 11y ago

Even though such a question would be more useful, I'm glad they didn't go that route as it would be dishonest: Too often we see the "why should I learn this?" questions that are really transparent "Why I haven't and won't bother -- my mind is firmly made up -- and here's how I pretend that I'm just being open minded in critiquing it" posts. Many of us are happy in our niche, and learning new things is often a PITA. We're happy with what we do and how we do it, with the tools and things that we're used to. And that's okay. The truth is that the language evolution is something that we can mostly just ignore, and if eventually something is truly dominant for a use case, we can easily adopt it with no real handicap over people who ground with it from the ugly beginnings (and many of those advantages will percolate to other platforms anyways. node.js is just layers and layers of compromises and problems, but it had a profound impact on other platforms, and truly changed the web serving game). And that's okay. But traditionally if someone posts resources for a particular language, it is bad form to engage in language wars, gloating, holier than thou (which the whole scarequote "maybe it isn't `trendy'" sorts of posts really are), etc, in the discussions. They're boring, we've had them literally thousands of times, and they are a distraction from discussing the actual contents of the post. I've noticed this particularly afflicts Go discussions. Python, Rust, D, Swift...all can be discussed rationally and productively. But if Go appears, it seems to be just threatening enough that it draws out people concerned about things they don't know.

geodel 11y ago
> I've noticed this particularly afflicts Go discussions. Python, Rust, D, Swift...all can be discussed rationally and productively. But if Go appears, it seems to be just threatening enough that it draws out people concerned about things they don't know. I totally agree with that. Apart from Swift which is by fiat, Go is the only language in top 15 or so which is used for serious work by developers who are not PL enthusiasts/theorists. This is putting serious, though I think unfair, demands on Go developers to justify their choice. So users of languages as diverse Haskell, Elixir, Java, Rust, Scala and many more keep beating Go with their favorite feature of preferred language. Somehow Rust specially stands out as its users/developers seems 100 times more interested in Go related discussions than vice versa. It is similar to politics saying: "You may not be interested in politics but it doesn't means politics is not interested in you"
- danieldk 11y ago
  It also doesn't help that Go users tend to deny weaknesses in Go. The typical line is 'you don't understand it because you have not used it long enough'. I have written Go intensively and less intensively over the course of last four years. Not surprisingly, most of the criticism are true.
  - geodel 11y ago
    I think criticism is all fine even by non-users. What I do not like is justifying to others who have no stake in project that why I used Go in place of lang of their choice.
  - karmakaze 11y ago
    Having used Go for some time now, and suspect that this attitude is a reflection of 'The Go Authors' and documentation. Although it's described as a systems language, it glosses over many low level details. The 'atomic' package says 'These functions require great care to be used correctly.' In attempting to find out what care is required, I ultimately discovered that the authors couldn't agree on how to express how to define its operation. When used for applications and running into shortcomings, the response is that it's not meant for that. The takeaway is that Go hits a spot between low-level systems programming and applications.