So, what other thing does the term "C++" refer to thats as popular as the language? I would really like to know, as I see no reason why custom rules are needed.

Well... everything aside, VM's are a way of the future because they will be the best performers. Pretty soon we'll have a mess heterogenous cores and systems and we will no longer be able to optimize binaries for a specific core configuration like we do now. Hell, they might even have different ISA's all together.

Given massively multi-core machines on every desk, the need for heterogeneous clusters would seem to decrease.

Go does not have a VM.

So, when does Allegro get a Go port/binding?

I'm happy to help out on one.

I will do hello world on the weekend, and you can do the rest
http://code.google.com/p/go/source/browse/misc/cgo/gmp/gmp.go?r=release

That's only valid for situations where vector processing is required. Most algorithms cannot be parallelized, so the need for a VM is minimal, if non existent. Parallelization of vector data can already be achieved optimally by using CUDA or OpenCL or whatever language exists that is complementary to C for this purpose.

The real problem is dependency management. I'd rather have my application not have any external dependencies, i.e. be a single executable, rather than not being optimized 100% for the target platform. If operating systems come with VMs preloaded or manage automatically VMs, then I am ok with it. This happens as we speak with operating systems that run in a virtual environment; you may also consider x86 assembly as the bytecode for x86 code (since each CPU decodes x86 differently to its internal real assembly language).

If we come to a situation you describe, then operating systems will have a VM installed by default, so the problem of managing the VM dependencies will go away.

Another solution would be an automated dependency manager (that does not interact with the user i.e. it discovers new versions and dependencies automatically, and installs updates automatically).

And then, there are real time applications. No VM could possibly exist for them, because their execution times should be predictable.

There's a couple of hurdles right now. First, the C binding program doesn't understand opaque types, e.g. typedef struct ALLEGRO_BITMAP ALLEGRO_BITMAP;, which we use a lot of. There's a patch in the bug tracker (#126).

More importantly, Allegro uses thread-local storage heavily and Go may multiplex goroutines onto its thread pool as it likes. Allegro will be unusable until there is a way to pin goroutines to specific threads, or something like that.

Turns out we can pin goroutines to OS threads. Attached the start of a binding (place in go/misc/cgo). I probably won't work on it more but feel free to pick it up if you like.

Attached for real now.

Perhaps what needs to happen is language designers need to realize that languages are just languages and should be officially implemented in virtual machines and native compilers, so the user is free to use whatever is most appropriate. Maybe it'll take designing a language with abstraction from the implementation in mind. Maybe that's Go, but maybe not.

Yeah, but it should only need to happen once. What's the point in going through the JIT process every time you run the program? If the program isn't changing then it should remain the same no matter how many times you JIT it so it might as well just stay compiled and just run natively.

There'd still be overhead in checking and loading the cache. Unnecessary overhead. It's a nice distribution model for average users, assuming the JIT is optimized for the platform, but that's no reason not to support straight to native compilation from the beginning.