[xemdetia]

I don't really feel like this is a fair statement if you have done any game engine related development. Even 'writing from scratch' is still gluing together a whole soup of libraries and many of those libraries are C API only. Fonts? Use freetype. PNG's? use libpng. COLLADA? Audio? Audio files? Input? OpenGL/DX?

As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.

This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.

If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.

[yellowapple]

A growing number of languages are ABI-compatible with C. A small but significant subset of those languages is ABI-compatible with C++. Quite a few languages (Perl 6, Julia, Tcl w/ critcl, pretty much everything that uses libffi AFAICT) are able to do this without having to write full-blown wrappers for a whole C/C++ library (though you still need to wrap specific functions in most cases).

[ihnorton]

Julia JIT compiles C calls via LLVM, so there's no libffi performance overhead (similar to LuaJIT's CFFI, though that does not use LLVM).

[yellowapple]

Neither does Tcl's critcl AFAIK (I think it just sticks the C code in a Tcl extension and compiles it using the system compiler). My intent there was just to list cases where wrapping a whole C/C++ library is unnecessary, not to imply that Julia uses libffi :)

On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?

[ihnorton]

Parse error on my part, excuse the pedantry :) Tcl is such a weird and wonderful language, and I occasionally miss it (though I don't miss working with a GUI written in C++ wrapped around tk).

[pjmlp]

On a past life I used to be an IGDA member, attended GDCE a couple of times, and knew personally developers working in a few European game studios, until deciding boring IT work was a better way to make a living and enjoying life.