13 ms·

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where t

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

hitekker 11y ago
Is the bunker-mentality a recurring pattern for all Google OSS? I've heard people talking about it in Dart, Angular, and V8/Chrome, and I'm not sure if it's true or not.
- lmm 11y ago
  I don't think it's Google specific. I'm quite a Scala fan but there was a time when many of us, probably myself included, had an unhealthy bunker-mentality.
bndr 11y ago
> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.
- m0th87 11y ago
  I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want <feature X>, you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.
  - jinst8gmi 11y ago
    It reminds me of the Java community when Sun stopped adding significant features for years after 2004. Every feature which wasn't added was widely considered by most Java developers as being in the name of protecting us from ourselves. When Java 8 came out suddenly some of those bad/evil features became flavor of the week. There's a tendency to try and convince yourself that the language designers made the best decisions at every turn, which isn't a healthy way of thinking critically.
  - amyjess 11y ago
    I've heard this same criticism levelled at the Clojure community, as well. Honestly, I can't think of any language community that's developed such a reputation for pitchforkiness towards suggestions as the Go and Clojure communities.
    - deleted 11y ago
      [deleted]
    - smw 11y ago
      What a strange argument. The difference is that clojure is about as extensible a language as it's possible to have. A macro system in a homoiconic language allows you to implement many types of semantic sugar or things that would be full-on 'language features' in other languages as a simple library. See core.async: https://github.com/clojure/core.async https://github.com/clojure/core.async
      - amyjess 11y ago
        Steve Yegge has written a lot about this. Much of his writings on the subject are in these mailing-list posts: https://groups.google.com/d/topic/seajure/GLqhj_2915A/discussion https://groups.google.com/d/topic/seajure/GLqhj_2915A/discus... Make sure to expand all of his posts on the thread, because he goes back and forth for a while. Much of it has to do with the community's attitude towards macros: there's an attitude of "macros are bad and you shouldn't use them", and people who write macros are often jumped on by the community. Here's one sentence of Steve's that sums it up: > When people announce: "hey, I made a loop macro!" the response absolutely can NOT be: "why can't you just write it as a series of maps and reductions?" And another: > If Clojure people all said "of course you can use macros! Of course you can use CL-style loop facilities! It's your code, do what you like! Feel free to use nonlocal exits all you like!" -- well, then it would be a lot closer to a Yes language. The problem is the way the community treats people who don't follow the prescriptive norms of the core Clojure people (norms which are often in conflict with the broader Lisp community).
        lispm 11y ago
- meesterdude 11y ago
  > You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive. thats more the developers than the langauge. I'm a diehard ruby guy, but when people talk about its shortcomings or the benefits of another language, i listen. It only clarifies what can and cannot be done, and what would be better done another way or in another language. I think its part the developer, part the community around it.
- moonchrome 11y ago
  But those languages are universally accepted as bad (well aside from Ruby, I don't know much about it because I already know Python and never felt I needed a different syntax for pretty much the same thing (arguably less used)) If someone started developing a language today and came up with C or PHP they would be criticized for many of the pitfalls of the mentioned languages and there would be a lot of improvements that could make those languages objectively better. But they are what they are because their design decisions were made under totally different environment than today and the advantage of using them is that you get to leverage everything built since then (well this argument is much stronger for C than PHP because PHP has alternatives that could be viewed as strictly better). But Go is a new language. It's trying to sell itself as a better solution to existing problems so the level of criticism is going to be (justifiably) much higher - it doesn't just need to meet minimum usability bar - it needs to be better than existing defaults, and significantly so to justify the cost of switching - both in terms of learning and porting.
  - Denzel 11y ago
    It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended). Just so happens that some developers at-large perceive an overlap, correct or incorrect, between their problems and Google's problems. So they use the language, and they're happy with it. Go is not trying to sell itself as a better general solution. It was built within the context of Google's problems. [1] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - moonchrome 11y ago
      >It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended). That's a good point - but if that is the case then any comparison to general purpose programming languages is pointless.
- 15155 11y ago
  Talk about the (legitimate) Haskell shortcomings and you'll be met with open, honest acceptance, mitigation strategies, and academic discussion. IRC, /r/haskell, whatever.
  - eropple 11y ago
    Rust too. The bunker mentality of the Go community is not unique, but its fervency, I think, is not currently matched anywhere else.
- amyjess 11y ago
  I don't know about that. C programmers can be defensive when it comes to changes in the core language, but they're very receptive of all kinds of third-party libraries, you don't see much of "if you want <feature X>, you're doing it wrong". Take, for example, object-oriented programming. If you try to confront a seasoned C programmer about how C sucks because it doesn't support OOP, instead of being told that OOP is bad and C shouldn't ever support it, you'll most likely get a response saying that C does support OOP with the proper libraries, such as GObject, and pointing out that large C projects like the Linux kernel are already object-oriented. Go, on the other hand, just pooh-poohes the concept. Clojure has a similar negative attitude. For example, the Clojure community is notoriously hostile to any suggestion of implementing Common Lisp's loop macro. There's no, "well, that's the beauty of Lisp, you can always write your own macros if you don't like what comes with it". Instead, you just get vitriolic condemnation of the whole idea of such a construct. If you write your own loop macro and post it in a Clojure community, the response is typically "why would you even think of writing such an abomination, what is wrong with you?", which is a disgustingly hostile way to treat people who are volunteering their time to contribute to the community.
laumars 11y ago
I think some of that stems from the fact that the arguments against Go are often over emphasised matters of personal preference, or just so frequently raised that it becomes tiresome to read. I love Go. I know it's an imperfect language and because of that I do often hate specific Go idioms. So I definitely don't have a "bunker mentality" when it comes to Go; nor any other language. But in terms of "getting stuff done" Go has generally served me - personally - better than any other language. I just get a little sick of hearing about how Go is a "bad language" when what people actually mean is "it's not productive for them personally." I can program in over a dozen languages, so I do have extensive experience outside of Go. And as someone who is language agnostic it never ceases to amuse and irritate me just how zealous people get when trying to prove personal preference as scientific fact.
- Retric 11y ago
  In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.
  - laumars 11y ago
    > In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. This is the problem though - I think many people expect there to be a "one language to rule them all". Personally I like having lots of different languages that excel at some problems even if that means they fall short at other problems. But I think some people either want to specialise in a specific language, or spend so much time looking for perfection that they miss subtle beauties amongst a forest of flaws.
    - nine_k 11y ago
      It's OK to see a language that has certain strengths but also some weaknesses due to the nature of the strengths. It's sad to see a language that has certain strengths but also some painful weaknesses for no good reason except that it's v.1. So far the best I've heard is something like "We understand there's a problem for certain users, and we don't rule out adding generic types some time later, but it's hard and our priorities are different". It is indeed not easy to do well (though Java has somehow managed to find a satisfactory solution). Well, I'll wait a few more years.
pkulak 11y ago
I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything around here at every opportunity. It's a way to put yourself above something with the least amount of effort.
- x1024 11y ago
  No, I've talked to Go people and they really do respond that way. Maybe my opinion is just one data point, but this entire thread seems to agree...
- gbhn 11y ago
  My (inexpert) opinion is that the kind of computer language researcher or practitioner interested in exploring how far you can go with type systems is dissatisfied with Go. But there are many types of static analysis which accomplish similar (or more dramatic) goals than what can be down with type analysis, and the simplicity of a language makes those kinds of analyses more reachable. Examples: gofmt and gofix. I think it's amazing what kinds of magic can be encapsulated with the type system, but my experience doing software is that complex types often end up being a hairball which is very change-resistant. Go's emphasis on lifecycle support for large programs may point us to new kinds of tools and methods. Whether those tools and methods end up being able to be encompassed by type theory is an open question, but it looks to me like Go is aimed in a great direction to raise the questions.
  - ionforce 11y ago
    What part of types is change resistant?
    - gbhn 11y ago
      To me, a lot of the more interesting areas of type research basically involve embedding logic into types. So types for sequencing of operations, types that constrain the data in them, etc. Those are awesome in that they enable static analysis to detect more sorts of logic errors in a digestible way, but my impression is that they end up encoding constraints in the type system that are then harder to change as the demands on the system evolve.
jshen 11y ago
The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make people a little more productive when using a generic library, but far less productive when trying to write a generic library. In short, these are entirely anecdotal and subjective points of view, so after the 1000th person says, "you are stupid, generics are amazing because .... my anecdotes" well eventually you tune it out. Last, there are a ton of languages out there that have generics, richer type systems, etc. Go is trying something different, and given the lack of real empirical data, lots of experimentation is the best thing. Let Go do it's thing, and let the other language do theirs, why demand that all languages need to make the same trade-off on these topics?
- sanderjd 11y ago
  I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective, but in reverse: after the 1000th person says, "generics are too complex and not having them is better because … my anecdotes", I eventually tune it out. Experimentation is definitely the right way to go (har!), but that doesn't imply that people should be mum about the results of their personal experiments! Obviously of these are actual scientific experiments, but when people (like the author of the OP) say "I've used Go and here is what I think", they are in essence reporting the findings of an "experiment" with the language. I don't think anybody is demanding that Go make the same trade-off as other languages, they're just documenting their thoughts on the affect of the various trade-offs.
  - dkuntz2 11y ago
    At least in the Go community, it doesn't seem like people are ever saying generics as a concept are bad, but that there are very real tradeoffs involved in adding them to Go, and they're the kinds of tradeoffs the language designers and maintainers have decided they don't want to make. I really like how simple Go is, but I also think generics are super useful, and that if Go could implement them in a Go-y way, I would be incredibly excited, and probably use it even more than I currently do. But I'd rather see the language focused on doing what it currently does well, and making sure it keeps doing things well, over seeing it try to throw in a poorly designed generics system like Java.
deleted 11y ago
[deleted]

hitekker 11y ago

Is the bunker-mentality a recurring pattern for all Google OSS? I've heard people talking about it in Dart, Angular, and V8/Chrome, and I'm not sure if it's true or not.

lmm 11y ago
I don't think it's Google specific. I'm quite a Scala fan but there was a time when many of us, probably myself included, had an unhealthy bunker-mentality.

bndr 11y ago

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

m0th87 11y ago
I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want <feature X>, you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.
- jinst8gmi 11y ago
  It reminds me of the Java community when Sun stopped adding significant features for years after 2004. Every feature which wasn't added was widely considered by most Java developers as being in the name of protecting us from ourselves. When Java 8 came out suddenly some of those bad/evil features became flavor of the week. There's a tendency to try and convince yourself that the language designers made the best decisions at every turn, which isn't a healthy way of thinking critically.
- amyjess 11y ago
  I've heard this same criticism levelled at the Clojure community, as well. Honestly, I can't think of any language community that's developed such a reputation for pitchforkiness towards suggestions as the Go and Clojure communities.
  - deleted 11y ago
    [deleted]
  - smw 11y ago
    What a strange argument. The difference is that clojure is about as extensible a language as it's possible to have. A macro system in a homoiconic language allows you to implement many types of semantic sugar or things that would be full-on 'language features' in other languages as a simple library. See core.async: https://github.com/clojure/core.async https://github.com/clojure/core.async
    - amyjess 11y ago
      Steve Yegge has written a lot about this. Much of his writings on the subject are in these mailing-list posts: https://groups.google.com/d/topic/seajure/GLqhj_2915A/discussion https://groups.google.com/d/topic/seajure/GLqhj_2915A/discus... Make sure to expand all of his posts on the thread, because he goes back and forth for a while. Much of it has to do with the community's attitude towards macros: there's an attitude of "macros are bad and you shouldn't use them", and people who write macros are often jumped on by the community. Here's one sentence of Steve's that sums it up: > When people announce: "hey, I made a loop macro!" the response absolutely can NOT be: "why can't you just write it as a series of maps and reductions?" And another: > If Clojure people all said "of course you can use macros! Of course you can use CL-style loop facilities! It's your code, do what you like! Feel free to use nonlocal exits all you like!" -- well, then it would be a lot closer to a Yes language. The problem is the way the community treats people who don't follow the prescriptive norms of the core Clojure people (norms which are often in conflict with the broader Lisp community).
      - lispm 11y ago
meesterdude 11y ago
> You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive. thats more the developers than the langauge. I'm a diehard ruby guy, but when people talk about its shortcomings or the benefits of another language, i listen. It only clarifies what can and cannot be done, and what would be better done another way or in another language. I think its part the developer, part the community around it.
moonchrome 11y ago
But those languages are universally accepted as bad (well aside from Ruby, I don't know much about it because I already know Python and never felt I needed a different syntax for pretty much the same thing (arguably less used)) If someone started developing a language today and came up with C or PHP they would be criticized for many of the pitfalls of the mentioned languages and there would be a lot of improvements that could make those languages objectively better. But they are what they are because their design decisions were made under totally different environment than today and the advantage of using them is that you get to leverage everything built since then (well this argument is much stronger for C than PHP because PHP has alternatives that could be viewed as strictly better). But Go is a new language. It's trying to sell itself as a better solution to existing problems so the level of criticism is going to be (justifiably) much higher - it doesn't just need to meet minimum usability bar - it needs to be better than existing defaults, and significantly so to justify the cost of switching - both in terms of learning and porting.
- Denzel 11y ago
  It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended). Just so happens that some developers at-large perceive an overlap, correct or incorrect, between their problems and Google's problems. So they use the language, and they're happy with it. Go is not trying to sell itself as a better general solution. It was built within the context of Google's problems. [1] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
  - moonchrome 11y ago
    >It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended). That's a good point - but if that is the case then any comparison to general purpose programming languages is pointless.
15155 11y ago
Talk about the (legitimate) Haskell shortcomings and you'll be met with open, honest acceptance, mitigation strategies, and academic discussion. IRC, /r/haskell, whatever.
- eropple 11y ago
  Rust too. The bunker mentality of the Go community is not unique, but its fervency, I think, is not currently matched anywhere else.
amyjess 11y ago
I don't know about that. C programmers can be defensive when it comes to changes in the core language, but they're very receptive of all kinds of third-party libraries, you don't see much of "if you want <feature X>, you're doing it wrong". Take, for example, object-oriented programming. If you try to confront a seasoned C programmer about how C sucks because it doesn't support OOP, instead of being told that OOP is bad and C shouldn't ever support it, you'll most likely get a response saying that C does support OOP with the proper libraries, such as GObject, and pointing out that large C projects like the Linux kernel are already object-oriented. Go, on the other hand, just pooh-poohes the concept. Clojure has a similar negative attitude. For example, the Clojure community is notoriously hostile to any suggestion of implementing Common Lisp's loop macro. There's no, "well, that's the beauty of Lisp, you can always write your own macros if you don't like what comes with it". Instead, you just get vitriolic condemnation of the whole idea of such a construct. If you write your own loop macro and post it in a Clojure community, the response is typically "why would you even think of writing such an abomination, what is wrong with you?", which is a disgustingly hostile way to treat people who are volunteering their time to contribute to the community.

laumars 11y ago

I think some of that stems from the fact that the arguments against Go are often over emphasised matters of personal preference, or just so frequently raised that it becomes tiresome to read. I love Go. I know it's an imperfect language and because of that I do often hate specific Go idioms. So I definitely don't have a "bunker mentality" when it comes to Go; nor any other language. But in terms of "getting stuff done" Go has generally served me - personally - better than any other language. I just get a little sick of hearing about how Go is a "bad language" when what people actually mean is "it's not productive for them personally." I can program in over a dozen languages, so I do have extensive experience outside of Go. And as someone who is language agnostic it never ceases to amuse and irritate me just how zealous people get when trying to prove personal preference as scientific fact.

Retric 11y ago
In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.
- laumars 11y ago
  > In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. This is the problem though - I think many people expect there to be a "one language to rule them all". Personally I like having lots of different languages that excel at some problems even if that means they fall short at other problems. But I think some people either want to specialise in a specific language, or spend so much time looking for perfection that they miss subtle beauties amongst a forest of flaws.
  - nine_k 11y ago
    It's OK to see a language that has certain strengths but also some weaknesses due to the nature of the strengths. It's sad to see a language that has certain strengths but also some painful weaknesses for no good reason except that it's v.1. So far the best I've heard is something like "We understand there's a problem for certain users, and we don't rule out adding generic types some time later, but it's hard and our priorities are different". It is indeed not easy to do well (though Java has somehow managed to find a satisfactory solution). Well, I'll wait a few more years.

pkulak 11y ago

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything around here at every opportunity. It's a way to put yourself above something with the least amount of effort.

x1024 11y ago
No, I've talked to Go people and they really do respond that way. Maybe my opinion is just one data point, but this entire thread seems to agree...
gbhn 11y ago
My (inexpert) opinion is that the kind of computer language researcher or practitioner interested in exploring how far you can go with type systems is dissatisfied with Go. But there are many types of static analysis which accomplish similar (or more dramatic) goals than what can be down with type analysis, and the simplicity of a language makes those kinds of analyses more reachable. Examples: gofmt and gofix. I think it's amazing what kinds of magic can be encapsulated with the type system, but my experience doing software is that complex types often end up being a hairball which is very change-resistant. Go's emphasis on lifecycle support for large programs may point us to new kinds of tools and methods. Whether those tools and methods end up being able to be encompassed by type theory is an open question, but it looks to me like Go is aimed in a great direction to raise the questions.
- ionforce 11y ago
  What part of types is change resistant?
  - gbhn 11y ago
    To me, a lot of the more interesting areas of type research basically involve embedding logic into types. So types for sequencing of operations, types that constrain the data in them, etc. Those are awesome in that they enable static analysis to detect more sorts of logic errors in a digestible way, but my impression is that they end up encoding constraints in the type system that are then harder to change as the demands on the system evolve.

jshen 11y ago

The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make people a little more productive when using a generic library, but far less productive when trying to write a generic library. In short, these are entirely anecdotal and subjective points of view, so after the 1000th person says, "you are stupid, generics are amazing because .... my anecdotes" well eventually you tune it out. Last, there are a ton of languages out there that have generics, richer type systems, etc. Go is trying something different, and given the lack of real empirical data, lots of experimentation is the best thing. Let Go do it's thing, and let the other language do theirs, why demand that all languages need to make the same trade-off on these topics?

sanderjd 11y ago
I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective, but in reverse: after the 1000th person says, "generics are too complex and not having them is better because … my anecdotes", I eventually tune it out. Experimentation is definitely the right way to go (har!), but that doesn't imply that people should be mum about the results of their personal experiments! Obviously of these are actual scientific experiments, but when people (like the author of the OP) say "I've used Go and here is what I think", they are in essence reporting the findings of an "experiment" with the language. I don't think anybody is demanding that Go make the same trade-off as other languages, they're just documenting their thoughts on the affect of the various trade-offs.
- dkuntz2 11y ago
  At least in the Go community, it doesn't seem like people are ever saying generics as a concept are bad, but that there are very real tradeoffs involved in adding them to Go, and they're the kinds of tradeoffs the language designers and maintainers have decided they don't want to make. I really like how simple Go is, but I also think generics are super useful, and that if Go could implement them in a Go-y way, I would be incredibly excited, and probably use it even more than I currently do. But I'd rather see the language focused on doing what it currently does well, and making sure it keeps doing things well, over seeing it try to throw in a poorly designed generics system like Java.

deleted 11y ago

[deleted]