Sunday, November 15, 2009

Go Qt Bindings Worth It?

So there's this language called Go from Google now, whose first impression to a programmer is "this is some odd-looking C" code. I do notice that the compile and link time is blazing fast, but let's take a look at the binary size of a simple hello world program, compared to C and C++ equivalents.

---------------------------------
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:

awainzin said...

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.

Tom said...

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.

Anonymous said...

Are you sure that it isn't statically linking the runtime inside the executable?

awainzin said...

@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...)

Henning said...

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.

awainzin said...

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

Ian Monroe said...

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. :)

Ville said...

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

p-Lo said...

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

Unknown said...

Go looks a lot like java there.

Jega said...

I think Jambi-Sources for D and Java bindings would be much more useful.

Unknown said...

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.

משה said...

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.