Comment by rickcarlino
2 months ago
We used Luerl, the underlying Lua engine, in production for years as a sandboxed scripting environment for FarmBot devices back in the day. Users could execute scripts directly on the device to control peripherals. It was a solid library and the community support was great. From an ergonomics perspective, developers preferred this approach over API calls. I am surprised more projects don’t provide a Lua scripting layer.
> I am surprised more projects don’t provide a Lua scripting layer.
Completely agree. I've been adding Lua scripting support to pretty much everything I make now. Most recently my programmable SSE server [1]. It's extended the functionality far beyond anything that I would have had the time and patience to do myself. Lua is such a treat.
[1] https://github.com/benwilber/tinysse
>Lua is such a treat.
It sure is.
I've been using Lua professionally and personally for some decades now, and I think that there is no need to be surprised that more projects don't provide a Lua scripting layer, because actually, Lua is everywhere. And the scripting aspect is one thing - but its not the only reason to use Lua.
Lua is so easily embeddable and functionally productive as a development tool, its not always necessarily necessary to have this layer exposed to the user.
Sure, engines and things provide scripting, and that is a need/want of the respective markets. Who doesn't love redis, et al.?
But Lua can be put in places where the scripting aspect is merely a development method, and in the end shipped product, things are tightly bound to bytecode as an application framework beyond scripting.
The point being, Lua is such a treat that it is, literally, in places you might least expect - or at least, will find under a lot of covers.
And after all, thats the beauty of it: as an embedded language/VM/function interface, Lua can sure scale to different territories.