We embed Lua and make use of it to act as rich glue on Windows. We wrote our own COM binding which is much simpler and faster than something like LuaCOM because

We embed Lua and make use of it to act as rich glue on Windows. We wrote our own COM binding which is much simpler and faster than something like LuaCOM because we don't use all of the features of COM (no installed classes / CoCreateInstance). It sounds simple on its face, but once you have a rich binding it can become complicated quickly as more and more code is written in the system and parts of code do things that you wouldn't expect or can't easily detect. We wound up writing our own debugger built into the embedding so that at any time we could pull up a console and interact with the engine and trace what was going on. Tools like that should be considered a necessity whenever you're creating an embedded script system inside a native code app. When you're wrapping any ref-counted system into a GC system (e.g. Javascript wrapping gobject) there is the potential for great disaster, either ref loops or mem corruption as discussed in other posts here. It just takes training and discipline to make sure something you're working on is built correctly according to the rules of the system. GC time has come up a bit as an issue, but it is mostly because our system is not linear in the sense that a game is. There are distinct states and times when the user is waiting and when they are not and it is an inopportune time to GC while in some specific states because it is perceived more by the end user. It is a balancing act to determine whether running the GC manually in the desired states provides a perceived or real difference than letting the engine run it whenever.