[HN Gopher] Lua for Elixir
___________________________________________________________________
Lua for Elixir
Author : davydog187
Score : 179 points
Date : 2025-05-13 13:03 UTC (2 days ago)
(HTM) web link (davelucia.com)
(TXT) w3m dump (davelucia.com)
| joshprice wrote:
| This is awesome! Can't wait to find some use cases to embed a
| sandboxed and safe mini Lua language in our apps.
|
| https://hexdocs.pm/lua/Lua.html
| davydog187 wrote:
| Thanks Josh, hope to see you soon, its been a while
| joshprice wrote:
| Likewise! ElixirConfUS?
| davydog187 wrote:
| Probably not, you should come to Code BEAM NYC, although a
| bit of a trek for you.
|
| I will be trying to travel more in 2026
| xvilka wrote:
| There is also Lua implementation in safe Rust - Piccolo[1]
|
| [1] https://github.com/kyren/piccolo
| behnamoh wrote:
| Recently, I had a simple Flask project, just a single Python
| file, and wanted to convert it to Elixir using AI. But what I got
| was a sprawling directory of modules and files in Elixir.
| Apparently, that's just how things are done in the Elixir world.
| That moment made me realize why some languages catch on while
| others struggle. If spinning up a basic web server already feels
| like jumping through hoops, I can't imagine the overhead for more
| complex projects.
|
| 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.
| devoutsalsa wrote:
| You can write a single file Elixir app if you want to. There's
| nothing preventing this. Setting up a simple web server w/ Plug
| is straightforward. You'll have the same problems you'd have
| with a non-trivial Flask app, which is that scrolling through a
| huge file is a pain.
| johnisgood wrote:
| My only issue when it comes to Erlang and Elixir (or Java and
| Kotlin) is that there are just so many files I need to open
| and keep track of. I do not blame the languages, of course,
| but it is the reason for why I use Go for less serious
| projects instead of Erlang / Elixir, because in Go it would
| typically be contained in one file, whereas in Elixir it
| would span across multiple files.
| ffsm8 wrote:
| You gotta be trolling...
|
| 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.
| johnisgood wrote:
| I am talking about the typical / usual case. In fact, you
| typically use "mix phx.new" for projects using Phoenix in
| Elixir, and it creates lots of files, as opposed to
| "import ..." in a single Go file. I never said that it is
| impossible to do in Elixir (or Java), but it is not the
| typical case.
| prophesi wrote:
| That's the typical use case if you want a web server. If
| you're writing for low-level devices, you'd use `mix
| nerves.new project_name`. If you're writing an Elixir app
| that won't be a web server, you'd use `mix new
| project_name`. If you're writing an elixir script, you'd
| use `touch script_name.exs`
| johnisgood wrote:
| Yes, of course. You are right.
| cess11 wrote:
| I tend to build my prototypes as single file Elixir
| scripts. These are sometimes rather bulky with a bunch of
| logic and IO modules with some helper modules on the
| side. It's only when I believe in the idea that I reach
| for phx_new and start writing tests and copying in code
| into a full Phoenix project.
|
| 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.
| johnisgood wrote:
| I typically use specific flags to "mix phx.new" that gets
| rid most of the files, especially JavaScript and whatnot.
| I am not at my PC right now and I forgot the flags, but I
| am sure you know what I am referring to.
|
| I never tried starting with Elixir scripts, I will give
| that a try.
| cess11 wrote:
| Someone linked the Plug docs elsewhere in this subthread,
| those show you how you can quickly launch a web server
| from a single file, including one with WebSocket
| capability.
|
| 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.
| johnisgood wrote:
| Side-note: considering you like Prolog, how come you are
| not writing Erlang instead of Elixir?
| victorbjorklund wrote:
| Typical no one writes a large web app in a single Go-
| file.
| johnisgood wrote:
| Well, that is unfair, because you added "large". If we
| compare large web apps between Elixir and Go, I am pretty
| sure Go would still have fewer files overall.
| mustermannBB wrote:
| Are you comparing Elixir with a framework as extensive as
| Phoenix to Go and "just" its standard http library? If so
| I'm not sure that would be a good comparison then.
| johnisgood wrote:
| No, you could import a full-blown framework and have it
| set up within one single file, in fact, that is how you
| usually start, typically... Unless you like having lots
| of files, of course. I have used such Go libraries /
| frameworks before, and it all started out as a single
| file, but with Phoenix, you start with lots of files. I
| am not saying it is a bad thing, I am just expressing my
| preference to fewer files. Organization and modularity
| are great, but in the case of Go, I create the files
| myself (so I am more aware of everything that is going
| on). In case of Phoenix ("mix phx.new"), it is done for
| you. Again, not saying it is a bad thing. I am fine with
| it by now, but it was overwhelming and demotivating in
| the beginning, as opposed to, say, Go.
| technojamin wrote:
| Here's a 22-line Elixir script that spins up a webserver:
| https://hexdocs.pm/plug/readme.html#hello-world-request-resp...
|
| 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?
| sodapopcan wrote:
| > 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."
| butterNaN wrote:
| That is categorically not "how things are done" in the Elixir
| world. Have you considered that the Advanced Next Token
| Predictor may be imperfect?
| __jonas wrote:
| It kind of is though, regardless of what the LLM did there,
| the 'happy path' with 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 for people used to more
| 'minimalist' web frameworks.
|
| 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.
| pessimizer wrote:
| Elixir is to Phoenix as Ruby is to Rails. The original
| comment was about Elixir, not Phoenix.
|
| 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?
| johnisgood wrote:
| Your comment comes across a bit hostile.
|
| 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.
| __jonas wrote:
| Ok sure, but Phoenix is the go-to solution for web
| projects in Elixir, especially newcomers are frequently
| told to just use Phoenix instead of trying to build on
| Plug.
|
| 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.
| bn-usd-mistake wrote:
| Isn't Phoenix more like Django (rather than Flask) which
| would also generate multiple files?
| sodapopcan wrote:
| Yes, and the same point should apply to Django from
| Flask. I think the point being made is that it's not
| immediately obvious that Elixir does have a
| microframework in Plug and that is a fair assessment.
| Just from my own observations this is because there is
| very little interest in such a thing (it's not zero, but
| it's low). Most of us have realized that using micro-
| frameworks leads you to inventing Phoenix/Django/Rails
| anyway so why not start there? Phoenix especially is
| pretty lightweight, even with "all those files." I think
| making Plug more prominent even in the Phoenix docs
| wouldn't be a terrible idea.
| sodapopcan wrote:
| Sigh, here we are with people taking what "AI" tells them as
| law. It's gonna be a fun next-few-years.
| bad_haircut72 wrote:
| You need to watch this
|
| 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
| sph wrote:
| I was afraid AI and vibe coders were gonna steal my job, but
| looks like I haven't got much to worry about, least of all AI-
| assisted dementia.
| arcanemachiner wrote:
| Elixir is somewhat lacking in training data compared to some
| more popular languages, so AI will often regurgitate nonsense
| (more so than in more popular languages).
|
| 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.
| rickcarlino wrote:
| 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.
| benwilber0 wrote:
| > 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
| Philpax wrote:
| Very nice, but it is confusing to name a library for using a
| language the same thing as that language. I suppose this is meant
| to be a temporary state of affairs while Lua (the library) gets
| merged into Luerl, but I would have personally called it Luerl++
| or such.
| davydog187 wrote:
| Author here!
|
| 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
| antfarm wrote:
| Have you considered "Luex", a nod to Luerl but with the
| typical Elixir suffix?
| shakna wrote:
| Humble appeal, because they'd win instantly: Please don't
| steal my useless project's name [0].
|
| [0] https://luarocks.org/modules/shakna-israel/luaex
| toast0 wrote:
| Within the BEAM ecosystem, consensus is to call something
| whatever2.
|
| If you wait long enough before replacing whatever2 with
| something that would be whatever3, you can go back to whatever
| (see pg -> pg2 -> pg)
| davydog187 wrote:
| If you're looking for a cool example of Lua running on the BEAM,
| check out the creator of Luerl (Robert Virding) space ship demo
|
| https://github.com/rvirding/ship-demo
| gilgamesh3 wrote:
| Cool project, congrats.
|
| 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.
| prophesi wrote:
| I would also personally prefer Elixir to Lua, but this would be
| great for allowing isolated/sandboxed BEAM processes to execute
| Lua code from your end users whom are likely unfamiliar with
| Elixir. As mentioned in the article, this is precisely what TV
| Labs uses it for to allow smart tv app developers to write and
| run tests for their apps.
|
| https://docs.tvlabs.ai/scripting/introduction/getting-starte...
| victorbjorklund wrote:
| This is more for your apps users. Like lets say you have a CRM
| saas written in Elixir. Then you can allow your users to script
| things in your app with Lua. If you allow them to use Elixir
| running in your app you might allow someone to hack your app.
| rdtsc wrote:
| Lua can help if you're handing this over to someone else not
| just devs who know Elixir.
|
| 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.
| davydog187 wrote:
| Elixir is not a sandboxed language, so you can't just accept
| arbitrary Elixir programs from users and execute them inside of
| your application without security concerns. Lua, on the other
| hand, can be executed in a sandboxed fashion, limiting and
| constraining the reach of user programs.
|
| 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/
| dpflan wrote:
| Is this influenced by "Embedding Python in Elixir"?
|
| https://dashbit.co/blog/running-python-in-elixir-its-fine
|
| It certainly is more attractive in implementation. Well done!
| davydog187 wrote:
| Both the Lua library and Luerl predate Pythonx. I started this
| library nearly 2 years ago, its only now that I'm releasing a
| stable version.
|
| 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.
|
| https://github.com/cocoa-xu/pythonx
| dpflan wrote:
| Very cool, thank you both for your contributions!
| codingbear wrote:
| what is the Lua equivalent for JVM ecosystem? An embeddable
| language which you allows for running user scripts in a sandbox?
| cess11 wrote:
| LuaJ, or Luna if you're brave. You can likely achieve something
| similar with other languages that runs on the JVM, like Kawa,
| Clojure or Jython.
| iLemming wrote:
| Does that mean I can now write Fennel to target BEAM?
| davydog187 wrote:
| There is a fennel channel in the discord/slack if you're
| interested. I'm not sure how successful it has been
| johnisgood wrote:
| Fennel compiles to Lua, so theoretically it should work.
|
| You should be able to do anything Lua does, run on any Lua
| interpreter, and use any Lua library.
| jkaufmann_ wrote:
| I have been waiting for this my whole life
| binary132 wrote:
| How sandboxed is BEAM really?
| cmdrk wrote:
| My understanding is that Luerl can remove various modules from
| being used, like preventing use of the IO library for instance.
|
| I would say BEAM itself is not particularly sandboxed, and
| certainly clusters of Erlang nodes assume a lot of shared
| trust.
| rdtsc wrote:
| davydog187, I just wanted to thank you for stepping up and
| lending Robert a hand. It's nice to see new releases and lots of
| cleanups happening in Luerl. The project is a real gem and it's
| nice to see new activity in it!
| davydog187 wrote:
| Thanks, I really appreciate that. While its not my main focus
| by any means, its been a really fun project to chip away at
| (both the higher level library and Luerl itself).
|
| I do think that it has the potential to be really great with
| continued investment
| interroboink wrote:
| 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.
|
| Okay, that's actually pretty cool (:
|
| 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).
| johnisgood wrote:
| LuaJIT is definitely amazing.
| pentacent_hq wrote:
| I've been considering adding Lua support to Keila for a while
| already. It seems like a perfect fit for when I'm going to
| implement email automation and want to allow custom business
| logic. This would certainly make that plan easier. Thanks OP for
| sharing the library with the community!
| davydog187 wrote:
| Let me know if you have any questions, I'd be happy to assist
| _acco wrote:
| This is so cool. A key benefit is that it's not embedding the C
| Lua runtime and compiler, but rather implements Lua in the host
| language (Elixir/Erlang).
|
| 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!
| dlojudice wrote:
| Fun fact (probably well-known fact for HN audience): Both Lua and
| Elixir were created by Brazilians. Lua by Roberto Ierusalimschy
| and team at PUC-Rio in 1993, and Elixir by Jose Valim in 2011
___________________________________________________________________
(page generated 2025-05-15 23:00 UTC)