Also, for a game server, often you want a lean-and-mean runtime library if only due to security concerns, especially if users can run their own custom scripts (as on a MUCK or MUSH). You really don’t want a user script to be able to, say, open a shell or dump files that are owned by the game server process or whatever.
One of the things I liked about Tcl was that it had an easy-to-enable “sandbox” mode which would disable every builtin that can access things outside of the scripting environment itself, and it had an easy mechanism for further restricting other builtins (such disabling for and while, if you wanted to guarantee the halting-ness of a user script – recursion had a stack size limit, of course, and any other iteration was easy to do using foreach) or enabling ones that were needed by user scripts after all.
Of course, any good game scripting language should have the ability to support multiple threads of execution (in the generic “I can pause this task and resume it later” sense, not necessarily meaning that tasks can be preemptively or concurrently scheduled) and the ability to abort those threads based on fine-grained criteria such as memory usage and time taken.
-- fluffy 2017-10-10 12:40 UTC