9 ms·

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue. It's infuriating that the same people making those comments are now taking credit for the solution, when they had to be dragged into even admitting the issue was legitimate.

camus2 9y ago
> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead of engaging into the bullshit they engaged in for years when dismissing this or that problem as irrelevant. Pike said "Go design" is done. Except that a language which design "is done" is a dead one.
- treehau5 9y ago
  > Pike said "Go design" is done. Except that a language which design "is done" is a dead one. Guess C is done for.
  - TJSomething 9y ago
    Except they updated C in 2011 and they're already working on C2X. http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm
  - andrewprock 9y ago
    I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.
    - pebers 9y ago
      To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.
      - astrange 9y ago
        Any code that declares variables in the middle of a function, // comments, or varargs macros is using C99.
      - xyzzyz 9y ago
        Linux is definitely not on ANSI C, and CPython is on C99 starting from 3.6.
      - simias 9y ago
        C99 took a while to be widely adopted mainly because some compilers where very slow on the uptake (I'm looking at you Visual C++) but now I would never consider using anything less than that for a new project. It's almost 20 years old! Many small quality of life improvements: stdint.h stdbool.h, inline, restrict, allowing variable declaration within the code, snprintf, variadic macros... Most of those were accessible through compiler extensions but having them in the standard means that you know it'll work everywhere on any compliant implementation. Linux definitely isn't conservative when it comes to the language, not only does it use modern features of the language but it even relies on GCC extensions and even sometimes on the compiler's optimizer to produce the correct code: https://unix.stackexchange.com/questions/153788/linux-cannot-compile-without-gcc-optimizations-implications https://unix.stackexchange.com/questions/153788/linux-cannot... I'm not super familiar with CPython but it also doesn't appear to limit itself to C89, see for instance this random file I opened: https://github.com/python/cpython/blob/master/Python/future.c#L23-L24 https://github.com/python/cpython/blob/master/Python/future.... You can see that `const char *feature` is declared in the middle of some code. It also uses "inline" in several places.
- pmarreck 9y ago
  I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go https://anvaka.github.io/common-words/#?lang=go
  - logingone 9y ago
    I've described Go programs as often looking like a listing of things that could go wrong.
    - jalfresi 9y ago
      In my opinion and experience, that is exactly what programs are
      - bboozzoo 9y ago
        Unless you're writing in Erlang, in which case you program the success path and 'let it crash' in a controlled manner.
        grogenaut 9y ago
        You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.
        tsuraan 9y ago
        Have you used erlang? Pattern matching is a big part of it, and pattern match failures always result in errors. So, if you have some function foo() that always returns ok or {error, Reason}, then in the "follow the happy path" style, you'd just have a line reading "ok = foo(),", and then if foo actually returns something else, you get a "crash". There's no assuming anything there, it's just the way the language works.
- rsc 9y ago
  The second half of the "Introduction" section of the blog post explains what "done" meant and why.
deleted 9y ago
[deleted]
kevinconaway 9y ago
> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change between the initial report and when cloudflare hit it. It was only until a Serious Industrial User (to borrow a term from Xavier @ OCaml) got bit in a very public way that they actually began thinking about what a clear solution would look like.
- hinkley 9y ago
  Well, but that's not waiting, that's stalling.
- hota_mazi 9y ago
  > We did what we always do when there's a problem without a clear solution: we waited And this is exactly why the Go designers don't understand language design, and how this ignorance shines through every single place in their language. Language design is about compromises. There is never a perfect solution, only one that satisfies certain parameters while compromising others. You, the designer, are here to make the tough choice and steer the language in a direction that satisfies your users. Besides, characterizing their position as "We waited" is very disingenuous. First of all, this is more stalling than waiting, and second, waiting implies they at least acknowledge the problems, which the Go team famously never does. Read how various issues are answered and then summarily closed with smug and condescending tones.
  - deleted 9y ago
    [deleted]
  - Jare 9y ago
    You are being deliberately negative here. Choosing to forego generics in favor of simplicity (and its impact along several axes) is a postcard example of a compromise. It is a tough choice that many people will be unhappy with, but there are also many Go programmers that are extremely satisfied with that direction. As for acknowledging, well, they have always been very clear about their position. It makes no sense to spend a decade answering the same question over and over with a long and elaborate response which the person asking has already seen and dismissed. I can understand them becoming condescending after a decade of facing people who act with a deliberately obtuse and holier-than-thou attitude. It's not like they have been lazy - every release of Go has had a large amount of improvements that matter. Working on generics would have meant sacrificing a (probably large) amount of them. (for the record, I dearly miss generics too!)
notjack 9y ago
Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.
- civilitty 9y ago
  Which is quite surprising. With open source projects it's usually the other way around...
  - FRex 9y ago
    Google already had incident with Guava where they didn't give a shit about the patches: https://news.ycombinator.com/item?id=3691587 https://news.ycombinator.com/item?id=3691587
- rsc 9y ago
  FWIW I think this is a fair criticism. We've had so much help from the Go community, not just for those two issues but also for essentially all the work we've done since the release in 2009. Go simply wouldn't exist without the community, and we're very grateful for it. I couldn't fit any kinds of thank yous into the talk, except for the credit to the overall community in the first few minutes, because I had a lot to say and only 25 minutes. It's possible I should have written an extended blog post that was more than just the talk, but I didn't - the blog post is just the talk, as it says.
conorh 9y ago
Would you mind providing examples of what you are talking about? My experience has been different - I find that the golang maintainers are thoughtful but also very very (very) busy people. So I find they tend to respond in a terse, and sometimes what might seem like an unfriendly way, but I haven't seen any of what you mention here.
- 43224gg252 9y ago
  Same, and to add: Go 2 has been planned for a while (since the beginning?) and I'm pretty sure the core developers tend to defer major new feature ideas (e.g. generics) to Go 2. If they implemented everything everyone asked for they'd have another screw-up like C++ or Java.
  - kasey_junk 9y ago
    Calling those languages screw ups is one of the funnier things I've seen in awhile.
    - 43224gg252 9y ago
      I know that both Java and C++ have a lot more issues than Golang ever will. I've used all three languages. Java has mile long class hierarchies, massive try-catch blocks, indentation as thick as my neck, and runs in a JVM. It's so bad there are already other implementations that people would much rather use. I also really don't like the file/project naming conventions. C++ is a whole other animal. The whole system of a Go program is typically very penetrable. You can trace the code down to the bottom of the stdlib or even the compiler builtins in seconds with ease (thanks to the excellent Guru and vim-go). In my experiences of C++, I doubt how many C++ programmers have ever had a look to the implementation of STL or iostream, which is hard to do ergonomically. Although some people occasionally call the opaqueness encapsulation and see it a good practice (which I don't agree). There are lots of cross compilation and static linking problems that don't arise with Go. There is the problem that one C++ code base will look completely different from others because no one in the C++ world follows conventions the way people in the golang world do. Compared to them Go is a very well thought out and elegant language.
canes123456 9y ago
The discussion is not about identifying problems. The issue is communicating the problem and explaining the impact. The Go team was wrong about monotonic time but the correct response is not to assign blame. Concrete examples and conversations are a better way to communicate a problem. This is what they are trying to communicate now.
- rsc 9y ago
  And if you _do_ want to assign blame, it's fine to put it on us. I did as much in the talk: "Just as we at Google did not at first understand the significance of handling leap second time resets correctly, we did not effectively convey to the broader Go community the significance of handling gradual code migration and repair during large-scale changes." Our fault, both times.
canes123456 9y ago
The discussion is not about identifying problems. The issue is communicating the problem and explaining the impact. The Go team was wrong about monotonic time but the correct response is not to assign blame. Concrete examples and conversations are a better way to communicate a problem. This is what they are trying to communicate now.
jasonwatkinspdx 9y ago
This hit a nerve, so I'm going to leave it up, but after thinking about it I also don't like how purely negative it is. I can't edit it anymore but I do want to make a follow up to say something things explicitly: I want to be clear I'm thankful for the effort everyone has put into golang. Making something people care about enough to love or hate is hard. Stewarding a FOSS project can be a very negative thankless experience as well. While I'm being critical above, there are also lots of examples of golang folks, core or otherwise, making really constructive and productive comments and contributions. I don't mean to trivialize that or ignore it.

camus2 9y ago

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead of engaging into the bullshit they engaged in for years when dismissing this or that problem as irrelevant. Pike said "Go design" is done. Except that a language which design "is done" is a dead one.

treehau5 9y ago
> Pike said "Go design" is done. Except that a language which design "is done" is a dead one. Guess C is done for.
- TJSomething 9y ago
  Except they updated C in 2011 and they're already working on C2X. http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm
- andrewprock 9y ago
  I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.
  - pebers 9y ago
    To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.
    - astrange 9y ago
      Any code that declares variables in the middle of a function, // comments, or varargs macros is using C99.
    - xyzzyz 9y ago
      Linux is definitely not on ANSI C, and CPython is on C99 starting from 3.6.
    - simias 9y ago
      C99 took a while to be widely adopted mainly because some compilers where very slow on the uptake (I'm looking at you Visual C++) but now I would never consider using anything less than that for a new project. It's almost 20 years old! Many small quality of life improvements: stdint.h stdbool.h, inline, restrict, allowing variable declaration within the code, snprintf, variadic macros... Most of those were accessible through compiler extensions but having them in the standard means that you know it'll work everywhere on any compliant implementation. Linux definitely isn't conservative when it comes to the language, not only does it use modern features of the language but it even relies on GCC extensions and even sometimes on the compiler's optimizer to produce the correct code: https://unix.stackexchange.com/questions/153788/linux-cannot-compile-without-gcc-optimizations-implications https://unix.stackexchange.com/questions/153788/linux-cannot... I'm not super familiar with CPython but it also doesn't appear to limit itself to C89, see for instance this random file I opened: https://github.com/python/cpython/blob/master/Python/future.c#L23-L24 https://github.com/python/cpython/blob/master/Python/future.... You can see that `const char *feature` is declared in the middle of some code. It also uses "inline" in several places.
pmarreck 9y ago
I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go https://anvaka.github.io/common-words/#?lang=go
- logingone 9y ago
  I've described Go programs as often looking like a listing of things that could go wrong.
  - jalfresi 9y ago
    In my opinion and experience, that is exactly what programs are
    - bboozzoo 9y ago
      Unless you're writing in Erlang, in which case you program the success path and 'let it crash' in a controlled manner.
      - grogenaut 9y ago
        You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.
        tsuraan 9y ago
        Have you used erlang? Pattern matching is a big part of it, and pattern match failures always result in errors. So, if you have some function foo() that always returns ok or {error, Reason}, then in the "follow the happy path" style, you'd just have a line reading "ok = foo(),", and then if foo actually returns something else, you get a "crash". There's no assuming anything there, it's just the way the language works.
rsc 9y ago
The second half of the "Introduction" section of the blog post explains what "done" meant and why.

deleted 9y ago

[deleted]

kevinconaway 9y ago

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change between the initial report and when cloudflare hit it. It was only until a Serious Industrial User (to borrow a term from Xavier @ OCaml) got bit in a very public way that they actually began thinking about what a clear solution would look like.

hinkley 9y ago
Well, but that's not waiting, that's stalling.
hota_mazi 9y ago
> We did what we always do when there's a problem without a clear solution: we waited And this is exactly why the Go designers don't understand language design, and how this ignorance shines through every single place in their language. Language design is about compromises. There is never a perfect solution, only one that satisfies certain parameters while compromising others. You, the designer, are here to make the tough choice and steer the language in a direction that satisfies your users. Besides, characterizing their position as "We waited" is very disingenuous. First of all, this is more stalling than waiting, and second, waiting implies they at least acknowledge the problems, which the Go team famously never does. Read how various issues are answered and then summarily closed with smug and condescending tones.
- deleted 9y ago
  [deleted]
- Jare 9y ago
  You are being deliberately negative here. Choosing to forego generics in favor of simplicity (and its impact along several axes) is a postcard example of a compromise. It is a tough choice that many people will be unhappy with, but there are also many Go programmers that are extremely satisfied with that direction. As for acknowledging, well, they have always been very clear about their position. It makes no sense to spend a decade answering the same question over and over with a long and elaborate response which the person asking has already seen and dismissed. I can understand them becoming condescending after a decade of facing people who act with a deliberately obtuse and holier-than-thou attitude. It's not like they have been lazy - every release of Go has had a large amount of improvements that matter. Working on generics would have meant sacrificing a (probably large) amount of them. (for the record, I dearly miss generics too!)

notjack 9y ago

Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.

civilitty 9y ago
Which is quite surprising. With open source projects it's usually the other way around...
- FRex 9y ago
  Google already had incident with Guava where they didn't give a shit about the patches: https://news.ycombinator.com/item?id=3691587 https://news.ycombinator.com/item?id=3691587
rsc 9y ago
FWIW I think this is a fair criticism. We've had so much help from the Go community, not just for those two issues but also for essentially all the work we've done since the release in 2009. Go simply wouldn't exist without the community, and we're very grateful for it. I couldn't fit any kinds of thank yous into the talk, except for the credit to the overall community in the first few minutes, because I had a lot to say and only 25 minutes. It's possible I should have written an extended blog post that was more than just the talk, but I didn't - the blog post is just the talk, as it says.

conorh 9y ago

Would you mind providing examples of what you are talking about? My experience has been different - I find that the golang maintainers are thoughtful but also very very (very) busy people. So I find they tend to respond in a terse, and sometimes what might seem like an unfriendly way, but I haven't seen any of what you mention here.

43224gg252 9y ago
Same, and to add: Go 2 has been planned for a while (since the beginning?) and I'm pretty sure the core developers tend to defer major new feature ideas (e.g. generics) to Go 2. If they implemented everything everyone asked for they'd have another screw-up like C++ or Java.
- kasey_junk 9y ago
  Calling those languages screw ups is one of the funnier things I've seen in awhile.
  - 43224gg252 9y ago
    I know that both Java and C++ have a lot more issues than Golang ever will. I've used all three languages. Java has mile long class hierarchies, massive try-catch blocks, indentation as thick as my neck, and runs in a JVM. It's so bad there are already other implementations that people would much rather use. I also really don't like the file/project naming conventions. C++ is a whole other animal. The whole system of a Go program is typically very penetrable. You can trace the code down to the bottom of the stdlib or even the compiler builtins in seconds with ease (thanks to the excellent Guru and vim-go). In my experiences of C++, I doubt how many C++ programmers have ever had a look to the implementation of STL or iostream, which is hard to do ergonomically. Although some people occasionally call the opaqueness encapsulation and see it a good practice (which I don't agree). There are lots of cross compilation and static linking problems that don't arise with Go. There is the problem that one C++ code base will look completely different from others because no one in the C++ world follows conventions the way people in the golang world do. Compared to them Go is a very well thought out and elegant language.

canes123456 9y ago

The discussion is not about identifying problems. The issue is communicating the problem and explaining the impact. The Go team was wrong about monotonic time but the correct response is not to assign blame. Concrete examples and conversations are a better way to communicate a problem. This is what they are trying to communicate now.

rsc 9y ago
And if you _do_ want to assign blame, it's fine to put it on us. I did as much in the talk: "Just as we at Google did not at first understand the significance of handling leap second time resets correctly, we did not effectively convey to the broader Go community the significance of handling gradual code migration and repair during large-scale changes." Our fault, both times.

canes123456 9y ago

jasonwatkinspdx 9y ago

This hit a nerve, so I'm going to leave it up, but after thinking about it I also don't like how purely negative it is. I can't edit it anymore but I do want to make a follow up to say something things explicitly: I want to be clear I'm thankful for the effort everyone has put into golang. Making something people care about enough to love or hate is hard. Stewarding a FOSS project can be a very negative thankless experience as well. While I'm being critical above, there are also lots of examples of golang folks, core or otherwise, making really constructive and productive comments and contributions. I don't mean to trivialize that or ignore it.