11 ms·

> You will realize eventually that what you first thought > was worth criticizing was actually a deep work of > genius. Funny, I found the more I used

> You will realize eventually that what you first thought > was worth criticizing was actually a deep work of > genius. Funny, I found the more I used it the less I liked it. > I’ve seen a lot of criticism of Go’s “shortcomings” > from people who are true experts in many languages > other than Go. Cool, normally I just call those people "experts". > I can’t recall similar criticism from someone who’s > worked with Go at a very deep level for a year or two. You would do well to understand the meaning of the term "survivorship bias".

Kiro 11y ago
What's with the condescending tone?
- jasode 11y ago
  Can't speak for peteretep but here's my guess... If you look at the quotes peteretep pasted, those "I-have-wisdom-that-you-don't" type of remarks can be interpreted as condescension. Therefore, it's human nature to respond to condescension with more condescension. To be clear, the blog author (Satish Talim) didn't write those quotes -- he's quoting Baron Schwartz.
- colin_jack 11y ago
  The quote he was commenting on had a very condescending tone too: " Do not complain about something you think is missing, wrong, or stupid. You are ignorant and new to the language, no matter how much of an expert you are on programming in general."
  - wiremine 11y ago
    I actually think it's pretty good advice. If you haven't used a language [1] before, park the opinion and get to work learning it. [1] or database or framework or whatever...
    - colin_jack 11y ago
      Yeah I agree, but to my mind its good advice delivered in a very condescending style.
      - OJFord 11y ago
        I don't think it's intended. I gather you refer to 'ignorant'(?) but it's innocent enough in meaning.
    - smosher_ 11y ago
      I think it's a canary. How many languages do you hear this said about? I've only heard it in regards to Go which is fairly pedestrian (read: looks and acts something like C / Java) as far as these things go. More exotic languages, which take the uninitiated longer to acclimate to, don't seem to be trying to tell people they're not allowed to think deeper about and question the design of the language. Good criticisms of Go were made on day 1 and are being made to this day, Rob Pike's ego notwithstanding. At the end of the day, if I see a problem with a developing language I am interested in, I'm going to report it. If I'm met with: "I don't know you but I'll assume you don't know what you're talking about" that's a second problem and I'm not about to double-down on it.
      - colin_jack 11y ago
        Is that really a general problem in the Go community? I ask because I've seen people explaining the tradeoffs Go makes pretty clearly online without any rudeness or condescending attitude.
        smosher_ 11y ago
        I don't know what it's like now. Rob Pike in particular made a lot of noise like this early on. There was a lot of parrotting of that, so it was hard to have a serious conversation. It seems like it's still getting play but I don't know how widespread that is today.
      - jerf 11y ago
fauigerzigerk 11y ago
The thing about Go is that some parts, like channels and goroutines (also some of the library designs and tooling), are so addictive that pretty soon it gets hard to imagine ever having to live without them. But I don't think everyone using Go really believes or supports this "but in practice it's not a problem and if it's a problem then the problem is YOU!" kind of response to every criticism. We live in a world of trade-offs. It's disingenuous to act like that wasn't the case.
- mda 11y ago
  "like channels and goroutines" Channels and goroutines advertised as the poster child of Go language features for simplifying concurrency since the beginning. When I tried to use them I was surprised how difficult actually it is to use them correctly, so many subtleties to deal with. Yes they are addictive, but I suspect beginners really are not using them correctly.
  - fauigerzigerk 11y ago
    Beginners don't remain beginners forever. My yardstick for whether or not I like a particular approach is looking at old code that I have written months ago. The more quickly I can get back into it without fear of breaking things, the better the design is. By that admittedly subjective standard, goroutines and channels have been a big success (compared to asynchronous code).
    - danieldk 11y ago
      By that admittedly subjective standard, goroutines and channels have been a big success (compared to asynchronous code). Well, your barrier is also very low :). Try e.g. Erlang's actor model.
      - deleted 11y ago
        [deleted]
      - fauigerzigerk 11y ago
sepeth 11y ago
Not directly related, but there's one tweet I like: "No no no no. The voice of newbies is one of your biggest assets. Why don't they understand? What is the confusion?" John Resig https://twitter.com/jeresig/status/584030561313943552 https://twitter.com/jeresig/status/584030561313943552
SomeCollegeBro 11y ago
I completely agree - the more I used it the less I liked it. I really enjoyed its implicit simplicity at first. The code I wrote had purpose and was clear, consice, and easy to understand. However, as the codebase grew larger I really ran into the issues more people talk about. Specifically lack of generics. I was using reflection to simulate this, however my performance was terrible on large sets of data. I had to end up relying on a code generator, which seems to be the direction Go is heading. Edit: Package versioning was another pain point, as someone mentioned below. Their built in package manager is almost too simple. As with anything simple, it's great at first but not so great when more complexities arise.
- pzduniak 11y ago
  The package versioning issue has been solved in 1.5 for most of the popular use cases with the vendor experiment. Works just fine for me!
  - drakenot 11y ago
    I hadn't heard about the vendor experiment. Is it now possible to point at individual tags/branches of a remote repository?
    - lobster_johnson 11y ago
      The new "vendor" system is basically that the Go compiler will look in vendor/ for your import before trying to traverse the GOPATH. This means you can manually download and freeze dependencies there. However, Go leaves the management of this vendor directory to you or some hypothetical helper tool — or with git submodules, for that matter. "go get", for example, still works just like before (ie., stores stuff in $GOPATH/src).
- bkeroack 11y ago
  If you are using reflection, unsafe or even interface{} heavily, you almost certainly are not writing idiomatic Go. This will doom you to frustration and a poor experience overall.

Kiro 11y ago

What's with the condescending tone?

jasode 11y ago
Can't speak for peteretep but here's my guess... If you look at the quotes peteretep pasted, those "I-have-wisdom-that-you-don't" type of remarks can be interpreted as condescension. Therefore, it's human nature to respond to condescension with more condescension. To be clear, the blog author (Satish Talim) didn't write those quotes -- he's quoting Baron Schwartz.
colin_jack 11y ago
The quote he was commenting on had a very condescending tone too: " Do not complain about something you think is missing, wrong, or stupid. You are ignorant and new to the language, no matter how much of an expert you are on programming in general."
- wiremine 11y ago
  I actually think it's pretty good advice. If you haven't used a language [1] before, park the opinion and get to work learning it. [1] or database or framework or whatever...
  - colin_jack 11y ago
    Yeah I agree, but to my mind its good advice delivered in a very condescending style.
    - OJFord 11y ago
      I don't think it's intended. I gather you refer to 'ignorant'(?) but it's innocent enough in meaning.
  - smosher_ 11y ago
    I think it's a canary. How many languages do you hear this said about? I've only heard it in regards to Go which is fairly pedestrian (read: looks and acts something like C / Java) as far as these things go. More exotic languages, which take the uninitiated longer to acclimate to, don't seem to be trying to tell people they're not allowed to think deeper about and question the design of the language. Good criticisms of Go were made on day 1 and are being made to this day, Rob Pike's ego notwithstanding. At the end of the day, if I see a problem with a developing language I am interested in, I'm going to report it. If I'm met with: "I don't know you but I'll assume you don't know what you're talking about" that's a second problem and I'm not about to double-down on it.
    - colin_jack 11y ago
      Is that really a general problem in the Go community? I ask because I've seen people explaining the tradeoffs Go makes pretty clearly online without any rudeness or condescending attitude.
      - smosher_ 11y ago
        I don't know what it's like now. Rob Pike in particular made a lot of noise like this early on. There was a lot of parrotting of that, so it was hard to have a serious conversation. It seems like it's still getting play but I don't know how widespread that is today.
    - jerf 11y ago

fauigerzigerk 11y ago

The thing about Go is that some parts, like channels and goroutines (also some of the library designs and tooling), are so addictive that pretty soon it gets hard to imagine ever having to live without them. But I don't think everyone using Go really believes or supports this "but in practice it's not a problem and if it's a problem then the problem is YOU!" kind of response to every criticism. We live in a world of trade-offs. It's disingenuous to act like that wasn't the case.

mda 11y ago
"like channels and goroutines" Channels and goroutines advertised as the poster child of Go language features for simplifying concurrency since the beginning. When I tried to use them I was surprised how difficult actually it is to use them correctly, so many subtleties to deal with. Yes they are addictive, but I suspect beginners really are not using them correctly.
- fauigerzigerk 11y ago
  Beginners don't remain beginners forever. My yardstick for whether or not I like a particular approach is looking at old code that I have written months ago. The more quickly I can get back into it without fear of breaking things, the better the design is. By that admittedly subjective standard, goroutines and channels have been a big success (compared to asynchronous code).
  - danieldk 11y ago
    By that admittedly subjective standard, goroutines and channels have been a big success (compared to asynchronous code). Well, your barrier is also very low :). Try e.g. Erlang's actor model.
    - deleted 11y ago
      [deleted]
    - fauigerzigerk 11y ago

sepeth 11y ago

Not directly related, but there's one tweet I like: "No no no no. The voice of newbies is one of your biggest assets. Why don't they understand? What is the confusion?" John Resig https://twitter.com/jeresig/status/584030561313943552 https://twitter.com/jeresig/status/584030561313943552

SomeCollegeBro 11y ago

I completely agree - the more I used it the less I liked it. I really enjoyed its implicit simplicity at first. The code I wrote had purpose and was clear, consice, and easy to understand. However, as the codebase grew larger I really ran into the issues more people talk about. Specifically lack of generics. I was using reflection to simulate this, however my performance was terrible on large sets of data. I had to end up relying on a code generator, which seems to be the direction Go is heading. Edit: Package versioning was another pain point, as someone mentioned below. Their built in package manager is almost too simple. As with anything simple, it's great at first but not so great when more complexities arise.

pzduniak 11y ago
The package versioning issue has been solved in 1.5 for most of the popular use cases with the vendor experiment. Works just fine for me!
- drakenot 11y ago
  I hadn't heard about the vendor experiment. Is it now possible to point at individual tags/branches of a remote repository?
  - lobster_johnson 11y ago
    The new "vendor" system is basically that the Go compiler will look in vendor/ for your import before trying to traverse the GOPATH. This means you can manually download and freeze dependencies there. However, Go leaves the management of this vendor directory to you or some hypothetical helper tool — or with git submodules, for that matter. "go get", for example, still works just like before (ie., stores stuff in $GOPATH/src).
bkeroack 11y ago
If you are using reflection, unsafe or even interface{} heavily, you almost certainly are not writing idiomatic Go. This will doom you to frustration and a poor experience overall.