---------------------------------
C:
#include
int main( void )
{
printf("Hello World\n");
return 0;
}
C++:
#include
int main( void )
{
std::cout << "Hello World!" <<>}
Go:
package main
import "fmt"
func main() {
fmt.Printf("Hello World\n")
}
---------------------------------
.... and the output sizes?
628K 6.out
16K helloc
16K hellocpp
Hmmm... speedy compile, strange-looking code, obscenely fat 39.25 times as large binary for a hello world file. Maybe as the programs grow larger, the overhead gets less and less, I'd need to test that or read an article about it, but from my first impression? Yikes... maybe not yet ready for Qt. But I'll definitely have fun playing with it anyway! =D
13 comments:
Ignore the faulty C++ code, blogger tried to "close" my bad html tags which are stream operators and it doesn't know that. Silly blogger.
Actually, I like Go and you should have tried the GccGo compiler.
A compiled language with MM and native concurrency support and without a lot of cruft is really compelling.
PS. When I try to rate the weirdness of the code realistically I think C++ is the worst tbh.
Are you sure that it isn't statically linking the runtime inside the executable?
@Tom: Ah I will give the GccGo a go... *sigh, terrible puns. And C++ sure has its share of weird constructs, I agree.
@Lorenzo: Not sure if that's the case, but given this size perhaps that's it after all. Let's see if I can't find a way to dynamically link (you'd figure it would default to this...)
As far as I understand the current versions of compiled Go-binaries contains the runtime library including the garbage collector. This might explain the size difference. Sooner or later this will be put into a shared library.
One main reason why I use Qt with Python and not with C++ is the compile speed.
@Henning: yes this seems to be the case and I'm trying to get GccGo compiling, but it has a few more dependencies that I need to find packages for or install manually from GCC instructions.
It has managed memory built-in (go compiled programs only need glibc and no equivalent to stdc++) of course its going to produce larger binaries for 'hello world'. This blog is a rather worthless "Which is more orange, apples or oranges?" type of comparison. Of course maybe it always produces larger binaries, but there's nothing here to say either way.
I'm also not sure if Qt bindings make sense though, given that it would mess up managed memory (the point of using Go pretty much) and its not OOP but something that I couldn't really figure out by just scanning their website. :)
I don't think GC is a huge problem - weirder things have happened (Jambi).
Regarding the inheritance issue - that's an interesting one. Someone will need to use some imagination, but I wouldn't be surprised if it was quite doable in the end (through sophisticated glue generation).
If you want to compile the hello-world c example statically for comparison purposes, you can use the "-static" flag for gcc.
My results for the plain c version:
4422 dynamic
575334 static
Of course the concern still remains that one doesn't have to compile c statically, but one probably does have to compile go statically for now...
Go looks a lot like java there.
I think Jambi-Sources for D and Java bindings would be much more useful.
You are ignoring the fact that Go embeds in your executable a garbage collector and other run time facilities. Taking that into account your 600k file is very small. Also, you'll notice if you write a non-trivial amount of code, the "baggage" will not grow along with the rest of the executable. Meaning in the end the difference in size for a real world program is depreciable.
Did you just judged a language by the size of it's compiled Hello World program?
Please show me a case where go failed and the size really matters.
Post a Comment