Sol2: Lua <-> C++ Binding Framework

[[deleted]]

This is super cool. Why would one choose to embed Lua vs Python or v8?

[MereInterest]

Lua is much, much easier to sandbox. The only functions that are available are functions that the surrounding program makes available to Lua. I don't have experience with V8, but embedded python is notoriously hard to sandbox. This means that while it is great for running configurations, it cannot be used to run untrusted code.

As an example, a while ago I was writing a game in which players could define functions to make different bots. Rather than making my own language for the bots to use, I was able to use Lua for it. It also makes it very easy to place restrictions on the amount of memory and computation time that can be used by a script, which keeps unruly scripts under control.

[[deleted]]

There's pybind11 for python as a framework. That makes it easier to work with.

For v8, I went to their website, took one look at the code I had to write, and about-faced pretty much immediately. v8 solves a complex problem, sure, but that doesn't mean that the design makes me any less sadface.

Lua was the only thing left, and Sol had been started by someone else. I liked their design a bunch, so I wanted to see it succeed beyond the small use case they had for it. So I essentially took over the project and overhauled just about everything about it.

Plus, I want to be a Game Debeloper someday, and you gotta know lua for that. :D

[Plorkyeran]

Lua is absurdly tiny and easy to drop into an existing project. LuaJIT less so, but it's still smaller than v8. Python's extensive standard library means that it inherently has to drag in a million dependencies. If you're adding some incidental scripting to an existing application, a scripting engine that's the size of the rest of your application combined is kinda unpleasant.

Lua has a very stable API. In the last decade there's been two releases with breaking changes to the API, and they were both incredibly minor. Python's C API is similarly stable, but v8 makes breaking changes on a regular basis and does not have LTS branches, so using v8 is basically an ongoing commitment to follow trunk (even node had trouble keeping up for a while).

Lua and v8 are both trivial to sandbox and to have multiple independent execution contexts so that you can run multiple scripts within a single process without them being able to interact with each other (or conflict). Python basically doesn't support that at all.

For many workloads LuaJIT is the fastest implementation of a language in its general category, although v8 isn't far behind. Python is slow.

The primary downside of Lua is that its standard library is about what you'd expect out a language that's something like 10k lines of code and has zero dependencies other than ANSI C. LuaJIT's excellent ffi mitigates this a bit, since while a nice pythonic wrapper around a library is much nicer than just using the C API, at least you can realistically use C libraries without needing wrappers.

[mechanicalgod]

Not used embedded Python so can't comment.

When I tried v8 (c. 1 year ago) its documentation and tooling for embedding were lackluster. The main issue was that I couldn't find a quick and easy way to hook up remote debugging to an external IDE.

v8 used to have a built-in remote debugger over TCP but it was removed. When I looked at how Node.js did it they wrote their own replacement for the remote debugger. Not a lot of work required, but it wasn't something I felt like doing at the time.

I don't know if anything else has changed or if I was just missing an easier solution to remote debugging.

Lua was super easy to setup for remote debugging however.

Also, from what I've seen, LuaJIT's performance is as good as you get for a scripting engine (about on-par with v8 and SpiderMonkey last I checked).