

Why Google's Go is a Bore - ThinkWriteMute
http://monoc.mo.funpic.de/go-rant/

======
shin_lao
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
_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
I'm a friend of the writer and we are actually looking at building something.
"Wequi", or the original word for the game Go.

------
samstokes
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.

------
ihumanable
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.

------
zck
>...you don't put in language features assuming a good programmer.

Interesting design goal.

~~~
barrkel
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
No, it doesn't in this case. The multiple return values make it impossible to
accidentally ignore an error.

~~~
d0mine
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

------
wglb
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.

------
uriel
_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
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
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
Even in Kernel programming, exceptions are useful. If you read
<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.

~~~
uriel
Go has goto.

Unlike goto as used in the linux kernel, exceptions will jump up the call
stack god knows where.

And in essence exceptions are not goto, but _camefrom_.

~~~
barrkel
Exceptions jump to the declared handler - i.e. the _right place_.

I remain convinced that far too many people have gotten wrong ideas about
exceptions from the bastardized implementations in C++ and Java.

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

