Lua for Elixir
davelucia.com
davelucia.com
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!
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
IMO this is really lazy in terms of naming and from a usage perspective, you get really tired of typing that out in code.
I think we can do better
Also, aren't you the author of jqex? ;)
Filtering which search results? On hex.pm that’s irrelevant. On good “library name + elixir”
If you wait long enough before replacing whatever2 with something that would be whatever3, you can go back to whatever (see pg -> pg2 -> pg)
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.
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.
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/
I will be trying to travel more in 2026
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.
You're literally responding to someone pointing out you don't need multiple files in elixir.
And the same is true for Java and kotlin. Heck even the official spring boots demo videos define everything in a single file nowadays.
Multiple files is just a convention, because otherwise your project will become unhandy eventually. That applies to Go as well.
When I started out with Phoenix I learned a lot from studying the boilerplate it can generate. If you just need a route and serve some JSON or a file on it you can turn off most of the code generation and do precisely that, in case you're sure that's what you want. I think the default being that you can immediately flesh out auth and CRUD for whatever tabular data model you want is rather sensible.
I never tried starting with Elixir scripts, I will give that a try.
In my opinion Elixir scripts punch way above their weight. It's trivial to pull in the same dependencies as you would in a full project and you can easily keep a set of five or ten template scripts just laying around and copy those when you want a quick start with some boilerplate for a set of dependencies that often comes in handy. You could do something similar with mix plugins but it requires a bit more effort.
A clever intern with a rather shallow two year 'bootcamp' education and no work experience picks up Elixir and Phoenix in a couple of months. People with background in enterprise algolians like Java and C# can also get productive in Elixir kind of fast since it allows similar patterns.
In my experience Lisp-like languages prepare well for Erlang, and that's a very rare background where I live.
The other reason I wouldn't use Erlang is that Elixir has a much more vibrant & active community. A lot of the Erlang libraries (as of a few years ago when I last looked) were quite old & there wasn't a lot of active development being doing on them. I like being able to track down answers to questions & documentation that is more current. And of course there are more likely to be off the shelf Elixir libraries available for download, too.
I prefer fewer files, usually, especially when I am just trying to show something up as soon as possible. I do not mind having a serious project written in Elixir (which I have) that spans across multiple files, though.
At any rate, what am I wrong about? I expressed my preference. When I want to get things done ASAP, I stick to Go these days (one file). If I know it is going to be a serious project, I stick to Elixir (multiple files). There is not much to it really. I apologize if I came across as argumentative.
If you have experience with these languages yourself, then you know that separation of concerns is a core principle. Elixir (and Erlang) projects, especially those built with Phoenix or OTP principles involve a multitude of files, even for relatively small applications. This is not because the languages require them per se, but rather because the conventions and idioms of both languages, especially within the OTP framework encourage modular, isolated units of behavior spread across separate files, which I do not think is a bad thing in itself.
> If you are just doing a script in Elixir it is just one file.
I know! I already left a comment agreeing with someone else saying that, which I have known already anyways.
Again, I was voicing my frustration with keeping track of a lot of files, which is not what I want to do in the case of not-too-serious projects, which is why I use Go for less serious projects, as I have previously mentioned. I do not always mind having a lot of files, but there are cases when I do, just like how one may not prototype in a low-level language as opposed to a high-level one.
In any case, I hope I could clarify well enough for you. Do we still disagree?
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."
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.
It also explicitly mentions Flask, which would be inane to directly compare to either Phoenix or Rails. How complex is your Django app, Mr. Python?
Regardless, I believe "something like Phoenix is using the phx.new and the generators which gives you a ton of files and structure that is a bit overwhelming " is true, it can be overwhelming, when the same thing in, say, Go, would be only one file.
The feedback from the Python person was a bit harsh, and evaluating a language based on LLM generated code is of course silly, but I think some of it still holds true. I'd love for Elixir to be a more approachable solution for simple web services.
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.