Why Google's Go is a Bore
monoc.mo.funpic.de
monoc.mo.funpic.de
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.
Complaints only add to the noise. Building things is the best way to add to the signal instead.
That said Go is a uglier than a dismembered hog. There's no beauty in Go.
funpic.de is obviously an old-fashioned sort of hosting company.
Interesting design goal.
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.
if result, ok := func(arg); !ok {
// handle error
}
// process result ..other stuff
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 stuffTFA 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.
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!
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.
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.
I remain convinced that far too many people have gotten wrong ideas about exceptions from the bastardized implementations in C++ and Java.
You can't mean very low level programming, since that is a very small fraction of all programming - and probably not the best domain of a general purpose programming language.
As I mentioned in another comment in this thread, I see exceptions as exactly equivalent to a rigorous approach to error codes.
I also note with interest that you describe the form as "handle the error and pass up an error code". This reads to me as a contradiction in terms. While the error code is still propagating, the error has not been handled. Some intermediate cleanup has perhaps been done, but normal code execution has not yet resumed. Moreover, exceptions have mechanically checkable formalisms for these phases of error handling.
What happens when your function raises an exception?
Rollback? Undefined?
That's the real difficulty.
More information here: http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161....
In particular you'll find an answer to your silly claim that exceptions are something that most sensible and experienced people agree foment bad error handling practices AND you'll find an explanation of why they are reasonable to omit from Go.