Ruby vs Lua as scripting language for C++

Question

I am currently building a game server (not an engine), and I want it to be extendable, like a plugin system.
The solution I found is to use a scripting language. So far, so good.

I'm not sure if I should use Ruby or Lua. Lua is easier to embed, but Ruby has a larger library, and better syntax (in my opinion). The problem is, there is no easy way I found to use Ruby as scripting language with C++, whereas it's very easy with Lua.

Toughs about this? Suggestions for using Ruby as scripting language (I tried SWIG, but it isn't nearly as neat as using Lua)?

Thanks.

Answer 1

I've looked at embedding Ruby into C/C++ before, and it seemed extremely difficult. There are a lot of challenges you'll face:

• Calling into Ruby from C/C++ requires 2 layers of functions to be written (one layer to call, and one to catch exceptions)
• Calling back into C/C++ from Ruby requires the normal SWIG-type work
• Moving data back and forth requires keeping careful track of allocations, since Ruby will want to garbage collect anything it can

I'm sure that this can be done, but it seemed extremely difficult to me, only doable if you can jump into Ruby in a minimum of entry points.

Answer 2

I've used Lua extensively in the past.

Luabind is really easy to use, there is no need for an external generator like SWIG, the doc is great. Compile times remain decent.

Biggest problem I've seen : lua is mostly ... write-only. You don't really have classes, but only associative arrays with a bit of syntaxic sugar ( object['key'] can be written object.key ), so you easily end up adding a 'member' in an obscure function, completely forget about it, and have side effects later.

For this reason, and this reason only, I'd prefer Python. Boost::Python is the basis for Luabind so both have a similar API (Luabind used to be slightly easier to build but not anymore). In terms of functionality, they are quite equivalent.

Not directly related : None of these can be reliably used in a multithreaded environment (so this depends on the complexity of your server).

• N Python threads : the GIL ( Global Interpreter Lock ) is on your way. Each and every time you use a variable in a thread, it's locked, so it kinda ruins the point, except for long I/O operations and calls to C functions.
• lua has coroutines, but they aren't parallelisable.
• Ruby threads aren't really threads, but similar to Lua's coroutines

Note that you can still create one environement for each thread, but they won't be able to communicate (except with a C++ machinery). This is especially easy in Lua.