4 ms·

Why Google's Go is a Bore

51 points by ThinkWriteMute 17y ago

rman666 17y ago
And what about that mascot character? Geez, that is the ugliest thing ever.
zck 17y ago
>...you don't put in language features assuming a good programmer. Interesting design goal.
- barrkel 17y ago
  Way to miss the point. Another way of putting it would be that languages should be designed so that there aren't gaping holes waiting for people to fall in. They should rather tend towards a "pit of success" - the easiest way to do things should be the correct way. Error code results make it really easy to ignore errors. That's not a good thing.
  - ori_b 17y ago
    No, it doesn't in this case. The multiple return values make it impossible to accidentally ignore an error.
    - d0mine 17y ago
      It requires at least 3 lines for every function call unless you ignore errors. Exceptions allow you to catch them without boiler-plate for each function. if result, ok := func(arg); !ok { // handle error } // process result ..other stuff On the other hand channels & goroutines allow in principle less verbose mode at the cost of additional parameter to every function in a stack. errors := make(chan Error) go handle_errors(errors) // read from errors // ... result := func(arg, errors) // write to errors in case of an error // process result ..other stuff
      - deleted 17y ago
        [deleted]
uriel 17y ago
yawn Yet one more rant completely missing the point and whining about the lack of exceptions (which at least as implemented on most languages most sensible and experienced people agree foment bad error handling practices, so the current Go approach is superior) and generics (still unclear if they make any sense given Go's interface system, which the author completely ignores.) And reading the rest of the gripes, the author clearly had zero interest in learning the language. > (Yes, that is a statement you see between "if" and the test. No, it serves no real purpose beyond obfuscation.) Way to show you have not learned anything about the language or even tried to write even a program a dozen lines long!
- barrkel 17y ago
  Fundamentally disagree with you on exceptions. Exceptions as implemented in e.g. Delphi or .NET work very well. In C++ the complexity of exception handling is deeply exacerbated by things like copy constructors - the bias in the language towards (what I call) value-oriented programming, rather than object orientation - and in Java exceptions are hobbled by the misguided notion that exceptions should be handled nearer the point of the throw rather than far away, in the relevant main loop of the app; hence the requirement to trace through annotations throughout the call graph from low-level throwing code to high-level catching loops, or basically avoid the bad design with RuntimeException.
  - jgrahamc 17y ago
    I agree with the person you are disagreeing with, in this case. Go is being touted as a systems programming language. My experience of very low level programming is that you want to know exactly what's happening, and especially when things go wrong. And you want to know what's gone wrong right at the point of it going wrong. Exceptions are the wrong technique for this form of programming. When doing systems work you are spending a lot of time dealing with error situations and hence the handle the error and pass up an error code form is appropriate.
    - sreque 17y ago
      Even in Kernel programming, exceptions are useful. If you read http://www.kernel.org/pub/linux/docs/lkml/#s15-5 http://www.kernel.org/pub/linux/docs/lkml/#s15-5, you'll see that goto's are used to reduce code duplication for error handling, which is essentially just a poor man's exception. More sophisticated exception handling in C can and has been done with longjmp as well.
samstokes 17y ago
Popover ads?! Nearly made me close the tab without reading a word of the article. funpic.de is obviously an old-fashioned sort of hosting company.
shin_lao 17y ago
I'm not sure the negative comments about UNIX, C braces and C++ templates help. They are unrelated to the case and make me feel the author isn't interested in being constructive. The debate between terse and ugly is a non-sense. Had the author a more open mind, he'd realize that the comfort zone where we place things we call "beautiful" is flexible and what one may find ugly the other may find beautiful.
- stcredzero 17y ago
  Well, I'm out of steam on this rant. Why the vituperative venom if Go is so uninspired and boring? It's the noise around it, really. It's yet another celebration of technical mediocrity that has caused computing to never really live up to its potential. This offends me at a profound level. Complaints only add to the noise. Building things is the best way to add to the signal instead.
  - ThinkWriteMute 17y ago
    I'm a friend of the writer and we are actually looking at building something. "Wequi", or the original word for the game Go.
- ThinkWriteMute 17y ago
  You'd be surprised how much actually gets done when being nice isn't forced and ranting once and a while is cathartic. That said Go is a uglier than a dismembered hog. There's no beauty in Go.
  - wglb 17y ago
    Forget being nice, how about some constructive criticism? That doesn't have to be nice, but in contrast with the article, has valuable content put forth.
ihumanable 17y ago
Stopped reading when I got to the first use of "UNIX virus" (actually I didn't but I should have). Unnecessary for the article, which itself is fairly lack-luster.
- deleted 17y ago
  [deleted]
wglb 17y ago
Boredom is a problem of depth and duration. TFA is putting expectations on GO that seem out of line with "Systems Implementation Language". The article expects that each new language will be an "advance", whereas in the school of Arthur Sale or C.A.R. Hoare often advocate removing stuff from a language to make it better.

rman666 17y ago

And what about that mascot character? Geez, that is the ugliest thing ever.

zck 17y ago

>...you don't put in language features assuming a good programmer. Interesting design goal.

barrkel 17y ago
Way to miss the point. Another way of putting it would be that languages should be designed so that there aren't gaping holes waiting for people to fall in. They should rather tend towards a "pit of success" - the easiest way to do things should be the correct way. Error code results make it really easy to ignore errors. That's not a good thing.
- ori_b 17y ago
  No, it doesn't in this case. The multiple return values make it impossible to accidentally ignore an error.
  - d0mine 17y ago
    It requires at least 3 lines for every function call unless you ignore errors. Exceptions allow you to catch them without boiler-plate for each function. if result, ok := func(arg); !ok { // handle error } // process result ..other stuff On the other hand channels & goroutines allow in principle less verbose mode at the cost of additional parameter to every function in a stack. errors := make(chan Error) go handle_errors(errors) // read from errors // ... result := func(arg, errors) // write to errors in case of an error // process result ..other stuff
    - deleted 17y ago
      [deleted]

uriel 17y ago

yawn Yet one more rant completely missing the point and whining about the lack of exceptions (which at least as implemented on most languages most sensible and experienced people agree foment bad error handling practices, so the current Go approach is superior) and generics (still unclear if they make any sense given Go's interface system, which the author completely ignores.) And reading the rest of the gripes, the author clearly had zero interest in learning the language. > (Yes, that is a statement you see between "if" and the test. No, it serves no real purpose beyond obfuscation.) Way to show you have not learned anything about the language or even tried to write even a program a dozen lines long!

barrkel 17y ago
Fundamentally disagree with you on exceptions. Exceptions as implemented in e.g. Delphi or .NET work very well. In C++ the complexity of exception handling is deeply exacerbated by things like copy constructors - the bias in the language towards (what I call) value-oriented programming, rather than object orientation - and in Java exceptions are hobbled by the misguided notion that exceptions should be handled nearer the point of the throw rather than far away, in the relevant main loop of the app; hence the requirement to trace through annotations throughout the call graph from low-level throwing code to high-level catching loops, or basically avoid the bad design with RuntimeException.
- jgrahamc 17y ago
  I agree with the person you are disagreeing with, in this case. Go is being touted as a systems programming language. My experience of very low level programming is that you want to know exactly what's happening, and especially when things go wrong. And you want to know what's gone wrong right at the point of it going wrong. Exceptions are the wrong technique for this form of programming. When doing systems work you are spending a lot of time dealing with error situations and hence the handle the error and pass up an error code form is appropriate.
  - sreque 17y ago
    Even in Kernel programming, exceptions are useful. If you read http://www.kernel.org/pub/linux/docs/lkml/#s15-5 http://www.kernel.org/pub/linux/docs/lkml/#s15-5, you'll see that goto's are used to reduce code duplication for error handling, which is essentially just a poor man's exception. More sophisticated exception handling in C can and has been done with longjmp as well.

samstokes 17y ago

Popover ads?! Nearly made me close the tab without reading a word of the article. funpic.de is obviously an old-fashioned sort of hosting company.

shin_lao 17y ago

I'm not sure the negative comments about UNIX, C braces and C++ templates help. They are unrelated to the case and make me feel the author isn't interested in being constructive. The debate between terse and ugly is a non-sense. Had the author a more open mind, he'd realize that the comfort zone where we place things we call "beautiful" is flexible and what one may find ugly the other may find beautiful.

stcredzero 17y ago
Well, I'm out of steam on this rant. Why the vituperative venom if Go is so uninspired and boring? It's the noise around it, really. It's yet another celebration of technical mediocrity that has caused computing to never really live up to its potential. This offends me at a profound level. Complaints only add to the noise. Building things is the best way to add to the signal instead.
- ThinkWriteMute 17y ago
  I'm a friend of the writer and we are actually looking at building something. "Wequi", or the original word for the game Go.
ThinkWriteMute 17y ago
You'd be surprised how much actually gets done when being nice isn't forced and ranting once and a while is cathartic. That said Go is a uglier than a dismembered hog. There's no beauty in Go.
- wglb 17y ago
  Forget being nice, how about some constructive criticism? That doesn't have to be nice, but in contrast with the article, has valuable content put forth.

ihumanable 17y ago

Stopped reading when I got to the first use of "UNIX virus" (actually I didn't but I should have). Unnecessary for the article, which itself is fairly lack-luster.

deleted 17y ago
[deleted]

wglb 17y ago

Boredom is a problem of depth and duration. TFA is putting expectations on GO that seem out of line with "Systems Implementation Language". The article expects that each new language will be an "advance", whereas in the school of Arthur Sale or C.A.R. Hoare often advocate removing stuff from a language to make it better.