That's the great thing about a mix of C++ and Python - you can scale up, scale down, port as you wish, program quickly, program detailed, etc. Such questions are not even relevant, because it's clear that the languages will not limit you.
Lua actually fits his criteria quite well, IMHO. It's fast, written in fully compliant ANSI C for portability, and very explicitly designed to be embedded in C / C++. It's also been in use in industry (such as at Petrobras, a big Brazilian oil company) for over a decade, as well as numerous games (<a href="http://www.lua.org/history.html" rel="nofollow">http://www.lua.org/history.html</a>). While the language isn't hard real-time, you can control (and just pause, or completely replace) the garbage collector.<p>As per the OCaml example, you could either change what C type Lua uses for its primary numeric type (it uses doubles by default) or use C userdata (a garbage-collector-managed pointer to a C struct), since the collection of numbers probably has some algorithmically relevant characteristics beyond just being a huge set of numbers.
Actually, if I was concerned about scaling to a 20-core CPU[0], I probably wouldn't use anything mainstream. It depends on the exact problem, of course, but that sort of thing is generally easier in functional languages.<p>Many of the author's questions can be reduced to "does it have a good C FFI?", but I'm not sure what the overall point is, or if these are just generalized suggestions to think about before starting a project. I'd like to know what the author would use in this situation.<p>[0] AMD has announced a 12-core Opteron for next year, so this isn't far-fetched at all.
Doesn't the recent port of many languages to the JVM somewhat nullify his concerns?<p>I am curious, because I don't know much about programming language implementations yet, just enough to know what I don't know.