I think the problem here is the title. After reading the article, I realise that when the author says Arc "is good for" games he means you can do games at all w

I think the problem here is the title. After reading the article, I realise that when the author says Arc "is good for" games he means you can do games at all with a bit of work. The details you mention should only worry you if you expected the author to be proposing that Arc is currently, out of the box, a competitive platform for games. By the way, you can roll your own audio support in any Scheme that has a FFI. You have to be a bit careful if you want low level access [1], but if you just want a play-wav function you can wrap SDL, fmod, OpenAL, or any other library that gives you audio through a C interface. The point here is not whether the Arc platform is suitable as-is for games, but whether it's worth the effort to make it suitable. You can amortize that effort over several games. Neither the C/assembly nor the Java/bytecode analogies are apt IMO. If you can't get access to some underlying platform facility in Java, bytecode won't help. As for C, when you move to assembly you sacrifice platform independence, while when you go down to PLT or the FFI the result is an Arc extension that, if well done, has the same objective qualities as if it had been provided by Arc in first place. [1] ...since that may imply writing a C callback that may be possibly be called in a separate OS thread. Most Scheme implementations don't support OS threads, but even those don't stop you from (carefully) using OS threads in your C extensions.