Interesting comparisons. However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.
C vs GO
11–20 of 184 posts
Re: C vs GO
#12Damn. I can't comment on the Go listings, but could he make his C code any less readable? What's the point of making the code so dense anyway? Without syntax highlighting I gave up pretty quickly.
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"
Re: C vs GO
#13Interesting comparisons. However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.
The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...
These languages also had OS fully implemented on them, just with tiny bits of Assembly to do the very low level stuff, similar to what C would require anyway.
The only advantage of C is that its runtime is so small, that in practice the OS is the C's runtime.
Re: C vs GO
#14I can't do system programming using Go on a platform for which there is no compiler. There is probably a reasonable C compiler for every platform in existence out there.
You use the compiler toolchain in OS A, while generating executables to run on OS B.
With a bootstraping compiler, you can use this technique to bring a native compiler to new platforms.
Re: C vs GO
#15Re: C vs GO
#16Damn. I can't comment on the Go listings, but could he make his C code any less readable? What's the point of making the code so dense anyway? Without syntax highlighting I gave up pretty quickly.
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…
Is not, he also inlined some things, e.g. this:
import ("flag";"fmt")
would be expanded to multiline by gofmt, as well as this: if i>0 { fmt.Print(" ") }
As to other things, I can't comment now, as I don't have time to read through all of the article at the moment.Re: C vs GO
#17Earlier quoted context omitted.
The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...
Ever heard of Oberon, Modula-2 and Modula-3? These languages also had OS fully implemented on them, just with tiny bits of Assembly to do the very low level stuff, similar to what C would require anyway. The only advantage of C is that its runtime is so small, that in practice the OS is the C's runtime.
Re: C vs GO
#18Earlier quoted context omitted.
The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...
Ever heard of Oberon, Modula-2 and Modula-3? These languages also had OS fully implemented on them, just with tiny bits of Assembly to do the very low level stuff, similar to what C would require anyway. The only advantage of C is that its runtime is so small, that in practice the OS is the C's runtime.
Re: C vs GO
#19I can't do system programming using Go on a platform for which there is no compiler. There is probably a reasonable C compiler for every platform in existence out there.
Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.
Also, OpenBSD, NetBSD, and Plan 9 in the works.
Re: C vs GO
#20Earlier quoted context omitted.
Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.
+ FreeBSD. Also, OpenBSD, NetBSD, and Plan 9 in the works.
Also there is gccgo, which AFAIK also works on Solaris and probably elsewhere.