The point is to show that Go is superior to C (which obviously is true but not for the reasons mentioned in the article).
Anything counts.
Go code is obviously formatted with gofmt.
C code is obviously not formatted with "indent -kr".
Liberal use of comma operator unseen in real world.
Look at example of yes(1) with error-handling.
Author doesn't use strdup(3).
But even if he did, it still doesn't make sense to call fprintf(3) once due to allegedly hard error handling.
Error handling is not common path, fprintf(3) doesn't fail!
He concatenates all string into once which makes it O(n^2) because of many many times strlen(3) is called (and kernel copied argv contents before that!).
I bet he did error checking wrong on C side (just checking return value should not be enough). It'd be interesting to see same code on Go side.
Obligatory quote:
"considering that bad code can be written in any language, any language
comparison performed using examples must be judged by the quality of the
examples in each language. it can't be all that hard to write a bad
example in language A and a good example in language B, and then proclaim
language B to be the winner -- this is how people compare languages all the
time, so either those who read them are bad programmers in any language (or
are not programmers at all) and don't know how to reject the bad examples,
or they already agree with the author of the comparison that language B is
better than language A. in either case, it's a waste of anything but
marketing money.
In fact, in pretty much every thread go turns up in. sigh I'm just going to link to my favourite review now, again (pertinent, and mentioned here only because the author of the original shared a favourite with me):
http://www.math.bas.bg/bantchev/misc/on-go.html
Quote: "But I know I am not going to love Go. True beauty evades this language. Go may be practical, but is also eclectic, and has taken some unconvincing or downright ugly design choices. It definitely lacks that subtle but unmistakable touch of elegance that makes a language great."
I'm not sure how to take that review given that his two main complaints seem to be:
1) That Go has i++ and not ++i. Don't even know what to say to someone who thinks this a major issue, really.
2) That the declaration syntax is 'unattractive' and different from other languages. Yes, the syntax looks a bit strange at first if you are used to C, but it is unquestionably cleaner and better, specially in more complex declarations. This is even covered in the FAQ: http://golang.org/doc/go_faq.html#declarations_backwards
His other complaints seem to be about the name of the language and how much some of the Go documentation acknowledges the influences of certain languages, which as he himself says, is just politics and not really relevant to the language itself.
At the same time there seems to be plenty of people who actually have used Go and love it, including the designers of other languages:
Anything counts.
Go code is obviously formatted with gofmt. C code is obviously not formatted with "indent -kr".
Liberal use of comma operator unseen in real world.
Look at example of yes(1) with error-handling.
Author doesn't use strdup(3).
But even if he did, it still doesn't make sense to call fprintf(3) once due to allegedly hard error handling. Error handling is not common path, fprintf(3) doesn't fail!
He concatenates all string into once which makes it O(n^2) because of many many times strlen(3) is called (and kernel copied argv contents before that!).
I bet he did error checking wrong on C side (just checking return value should not be enough). It'd be interesting to see same code on Go side.
Obligatory quote: "considering that bad code can be written in any language, any language comparison performed using examples must be judged by the quality of the examples in each language. it can't be all that hard to write a bad example in language A and a good example in language B, and then proclaim language B to be the winner -- this is how people compare languages all the time, so either those who read them are bad programmers in any language (or are not programmers at all) and don't know how to reject the bad examples, or they already agree with the author of the comparison that language B is better than language A. in either case, it's a waste of anything but marketing money.
...
#\Erik"