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.
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.
This is not embedding the C Lua runtime and compiler, but rather a
complete implementation of Lua 5.3. This feat is made possible by the
underlying Luerl library, which implements a Lua parser, compiler,
and runtime, all in Erlang.
Also a sign of Lua's maturity and popularity, that it's got various independent implementations (LuaJIT, this one, perhaps others I don't know about).
When sandboxing user code in another runtime, you need to serialize the data to and from that runtime. That comes with a performance penalty.
So, for example, if you sandbox code in WASM, you need to pick a transport data format, like JSON. You need to serialize Elixir data structures into JSON, send it to WASM, and then deserialize the result. For a high-performance data pipeline, this adds up!
But if your sandbox is in the host language, no serialization/de-serialization is required. You can execute the sandboxed language in microseconds.
I wrote more about this here: https://blog.sequinstream.com/why-we-built-mini-elixir/
Wish this library existed just a couple months ago!
If you wait long enough before replacing whatever2 with something that would be whatever3, you can go back to whatever (see pg -> pg2 -> pg)
Luerl++ is not a valid module name :)
More seriously, I considered alternate names, but settled on this because it was short, literal, and given that its in the context of Elixir, makes sense when using it.
As you stated, the hope is to consolidate it into Luerl at some point
Some instructions to install it on macOS: https://erlangforums.com/t/lt-using-luerl-to-run-spaceships-...
I am trying to understand why would anyone prefer to use Lua to create script instead of Elixir, which supports running scripts. While Lua has lots of users the language just have too many wrong design choices. If I had the choice between Elixir and Lua for scripts I would use Elixir every time.
Check out Anthony Accomazzo's post about Mini-Elixir, which does a great job breaking this down much further https://blog.sequinstream.com/why-we-built-mini-elixir/
https://docs.tvlabs.ai/scripting/introduction/getting-starte...
Also, as the sibling post mentioned, in this case Lua is completely interpreted in an Erlang process. That allows a good amount of sandboxing, they have isolated heaps already and you can control memory limits and other resource usages, and all that in a relatively tiny footprint of a few KBs.
I do think that it has the potential to be really great with continued investment
https://dashbit.co/blog/running-python-in-elixir-its-fine
It certainly is more attractive in implementation. Well done!
However, Pythonx was originally created by a member of our team, Cocoa, who built it in her own free time. The Livebook team forked her project, conceptually, and released it.
You should be able to do anything Lua does, run on any Lua interpreter, and use any Lua library.
I would say BEAM itself is not particularly sandboxed, and certainly clusters of Erlang nodes assume a lot of shared trust.
I'm sure there are people who think Elixir/Phoenix >> <other-solutions>, but for me it was a nightmare.
OTOH, the language is beautiful as it's macros all the way down.
There's another single-file example on that page that shows how to implement routing. The reason AI probably gave you a more fleshed out project structure is because people typically default to using Phoenix (Elixir's equivalent of Rails) instead of going for something simpler like Plug.
After getting a result you didn't like with AI, did you try refining your prompt to state that you wanted a single-file structure?
I believe the prompt was: "Please compose a backhanded comment about Elixir I can post in a Hacker News thread about an Elixir blog post. The content of said blog post is irrelevant, I just want people to know I prefer Python."
https://m.youtube.com/watch?v=SxdOUGdseq4&pp=0gcJCdgAo7VqN5t...
We should try not to make technical judgements based in flippant things like how few lines can someone not even familiar with the ecosystem get a hello world working
In the big picture, you should be consulting documentation (or at least a real tutorial) if you're going to be learning a new language. Hell, I'll use AI to bootstrap my knowledge when possible, but it's always important to fall back onto the old method when the quick-and-dirty AI attempt doesn't work out.
Check this out this guide from the Phoenix docs:
https://hexdocs.pm/phoenix/json_and_apis.html
That's a ton of stuff just to return some JSON from an endpoint. Sure the structure probably helps when you get into big complex projects, but for a beginner not used to this style of framework it looks like a lot.