Hacker News Reader

Comment by kragen | Hacker News Reader

What language did you find was easier to embed, and how does it handle the lifetime management that Lua's embedding API handles with its stack?

The language itself may be a matter of taste. I prefer languages which, "in the face of ambiguity, refuse the temptation to guess," but certainly I've spent enough time using Perl, bash, JS, and BASIC to be able to deal with Lua's relatively mild level of DWIMminess.

View on HN

I would use quickjs today for embedding over lua. Everyone know js nowadays and quickjs is really nice. The advantage lua has is library support via Lua rocks. Maybe someone can comment on the quickjs ecosystem?

It sounds like you're saying quickjs is what you'd try if you wanted to embed a language, but you haven't tried embedding quickjs yet?

I think there’s a fork called quickjs-ng that’s actively maintained on GH. Should be able to use it as a lib maybe with some externing.

I’ve also had luck using it in a wasm runtime thanks to quickjs-emscripten. Good if you need sandboxing sans full process isolation.

Thank you for sharing your experience! Wasm provides full process isolation, doesn't it? Do you mean that QuickJS provides cheaper sandboxing than wasm?

I’m not sure if wasm would be considered full process isolation but it does provide software based sandboxing. I’m referring to running quickjs in wasm by compiling it with emscripten.

https://github.com/justjake/quickjs-emscripten

I see, thanks!

I have experience of embedding and modifying both QuickJS and Lua. QuickJS is not bad, but Lua is a lot easier and has fewer bugs. JavaScript is a very complicated language under the surface; I think very few people, if any, know and remember all its quirks.

Amazfit's Zepp OS uses quickjs to run 3rd party watchfaces and apps in their smartwatch

I was surprised to find out I'd been wearing javascript on my arm all this time

While QuickJS is nice, JavaScript as a language is much uglier and more complicated than Lua.

Python is arguably easier since you don't need to handle non-native stacks at all; you just have a straightforward mapping of Python operations to C functions that you call with regular arguments, as usual.

With Python's extension API, you have to carefully incref and decref Python values to ensure that you don't either leak memory or deallocate data that's still in use. That's what the Lua stack interface saves you. It's not a call stack, which seems to be what you're thinking of.

Lifetimes and references are things to consider in Lua integration code too. See luaL_ref() rationale and why you can’t lua_pop() a string that is in use. The fact that gc doesn’t happen instantly 99.99999% of the times doesn’t save you from thinking about it.

Not that this was a hard topic in a language where lifetimes are the main concern and business as usual. In C/etc you can’t hold anything without a ref or some sort of a lifetime guarantee. What makes it special wrt Lua/Python?

Yeah, I didn't mean to say you didn't have to think about lifetimes at all when embedding Lua, just that the stack, weird as it is, seems to simplify that kind of thing rather than complicating it (even if you do occasionally have to luaL_ref). But if there's a clearly better alternative, I'd like to know about it. Constantly calling Py_INCREF and Py_DECREF isn't it.

Delayed GC seems like it might add headaches for this kind of thing rather than removing them, because your bugs may take a while to show up in testing.

Lua stack basically works as an arena if you aren’t eager to clean it.

I guess in C one could macro hack himself a similar arena to borrow objects from python runtime.

In C++ it’s a matter of befriending a smart pointer with ref/unref calls. It was probably done hundreds of times in all sorts of python embedding wrappers.

Indeed, but the rules for doing so are straightforward and easy to apply almost mechanically. Indeed, if you are writing in C++ or Rust, you just use a smart pointer that does it for you.

Reply on news.ycombinator.com