The whole article gives me a 'I know LUA and have been using it for years, I also tried MicroPython for a couple of hours, so now I'm ready to draw conclusions' vibe. With some 'Python vs C' on top of it. Not everything written about MicroPython is factually incorrect, but some of the things are so over the top to the point that it becomes ridiculous. Just one example:
MicroPython can be equally readable, but in practice, many projects end up with blurred layers between system code and scripting. That creates a maintenance burden as projects grow.
Yeah, right. Even if this is the case (I find it hard to belive the author has really seen 'many' sort of professional MicroPython projects), where's the proof the language used was the deciding factor in that. And not the project management for instance. Or simply the dev's architecturing abilities.
When I decided to create a game engine where the game could be entirely scripted in a scripting language, I was choosing between JavaScript (QuickJS), Python (Boost.Python), and Lua (Sol2).
The ease of embedding Lua, even with a C++ wrapper, is incredible. With little effort, I now have something I consider “ready”.
A nice thing about seeing an engine or application support Lua for scripting is that it implies Fennel can be used (and transpiled to Lua). Or at least that is highly likely unless something unusually weird is going on.
I have been developing Lua-heavy embedded products as a freelancer for about 20 years now, including VoIP devices, home automation controllers, industrial routers, digital video recorders, and more. These systems typically consist of a Linux kernel, some libc implementation, the lua interpreter and a few 3d party libs support libs to help building the app. The Lua apps ranges from 30k to 100k lines of code, depending on the application. Some of these devices can be considered 'small' in 2025 terms: 8MB of flash, 64MB of ram. Lua is doing great here.
All of these products are still alive today, actively supported and making my customers good money.
Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.
For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.
I am currently working on an embedded system with 264Kb of RAM and 4Mb of flash. Do you think Lua could be used in such limited settings? I am also considering the berry scripting language [0].
I haven't worked on a system that limited (not even OpenWRT routers) since a dev board in college.
The experience I had there might be your best bet for something productive. That board came with a 'limited C-like compiler' (took a mostly complete subset of C syntax and transcribed it to ASM).
You'll probably be doing a lot of things like executing in place from ROM, and strictly managing stack and scratch pad use.
The 64MB of RAM and 8MB (I assume that's 64Mbit) of ROM allow for highly liberating things like compressed executable code copied to faster RAM, modify in place code, and enough spare RAM otherwise to use scripting languages and large buffers for work as desired.
The embedded world is really vast. If it's something safety critical, regulations won't allow it. But the regulations say nothing about all the test rigs you'll be building. IoT is another domain where people do whatever they find convenient.
Python does have the 'there should be one, preferably only one, way to do it' mantra, but to me it utterly fails at that, and is in fact a bit of a 'kitchen sink' or 'armchair' language.
That is it's strength in some ways, it's easy and approachable, and has more libraries than perhaps any other language, so you can usually get something working fairly quickly.
But it's not so suited to sparse environments. You can't easily turn a plump armchair with automatic footrests and telescoping side-tables into a plywood Eames.
Python also seems to have more issues with stability, in the sense that things randomly stop working when you upgrade from version 3.x to 3.x+1. Lua might not be perfect either, but at least it seems common that a platform supports a range of Lua versions instead of forcing an immediate upgrade.
You use micrpython when you have lots of horsepower and need something fairly robust on the network.
You use C/C++ if you need precise control over power, memory or CPU. Even though if you're doing network stuff its much harder to do quickly and securely. (THere might be better embedded TLS support now)
Lua is frankly just sparkling C. Sure if someone has create a bunch of libraries for you, then great, if not, you've now go to support lua toolchain, and your own microcontrollers toolchain, and port what ever control lib the manufacturer provides yourself.
What’s the dev experience actually like for serious Lua? I’ve only used it for some basic neovim configuration. The dynamicism and lack of type hinting in Python that was the norm when I started having to review professional code, after transitioning from pure mathematics, was a major cognitive blocker for me. With a math paper I could typically skim the first few pages to map the author’s particular symbology (if non-standard) and know exactly what was being expressed. I could never do that with untyped code.
Lua can be quite an elegant language once you get to know it well, but you can still use it like most other programming languages, it's not that weird. There are quirks like arrays starting at 1 (and all arrays being hash tables) but they don't take that long to get used to. The real strength is in the ecosystem and implementation itself, it's designed to be easily embedded into applications and there's not really much else like it. Some developers want to incorporate a scripting language into their project and get turned off by Lua's quirks and choose something else, but it usually ends up causing more problems than it was meant to solve.
On typing, there's only a few main ones you need to worry about—strings, functions, tables and numbers. I don't think it does weird things like JS where it converts between them without asking. Luau adds some type hinting if it's a big point of concern but I haven't really looked into it much.
While I understand the aversion, I can't help but think that people miss out on some really cool experiences when they balk at stuff like 1-based arrays or parens in Lisp or whatever. Sure, those quirks may remain deal breakers after you've given the language a thorough try, but you may also gain super interesting new perspectives in the process.
> What’s the dev experience actually like for serious Lua
The dev experience for lua is f-ing awful.
The language is small, but not “simple”; it’s stuck in 1985.
The tooling is nearly non-existent and the stuff that does exist is a joke.
The few libraries that exist are awful and barely maintained; the maintained libraries are maintained by neckbeards with a god-complex.
The community is “reimplementing everything by hand is the right way to do it AND ALSO you’re an idiot doing it wrong” toxic. There are a million good reasons why it’s only has a foothold in nginx and Roblox territory.
It’s not a joke to say that it’s f-ing terrible all the way around.
It might not be a joke, but it is just your fucking opinion, man. Seriously, this kind of vitriol is uncalled for and only serves to make you look pathetic as fuck.
> [bolded] Lua isn’t just a high-level language. It’s an embedded dev strategy.
I find it difficult to take any writing seriously when it uses phrases like this.
The whole article gives me a 'I know LUA and have been using it for years, I also tried MicroPython for a couple of hours, so now I'm ready to draw conclusions' vibe. With some 'Python vs C' on top of it. Not everything written about MicroPython is factually incorrect, but some of the things are so over the top to the point that it becomes ridiculous. Just one example:
MicroPython can be equally readable, but in practice, many projects end up with blurred layers between system code and scripting. That creates a maintenance burden as projects grow.
Yeah, right. Even if this is the case (I find it hard to belive the author has really seen 'many' sort of professional MicroPython projects), where's the proof the language used was the deciding factor in that. And not the project management for instance. Or simply the dev's architecturing abilities.
This is just an ad in a trade rag masquerading as an article or something. It's an ad for that Xedge Lua framework.
Much of the article resembles chatgptese... though I suppose for adslop it doesn't matter whether it's written by a human or an llm
When I decided to create a game engine where the game could be entirely scripted in a scripting language, I was choosing between JavaScript (QuickJS), Python (Boost.Python), and Lua (Sol2).
The ease of embedding Lua, even with a C++ wrapper, is incredible. With little effort, I now have something I consider “ready”.
Not to mention, it’s a very lightweight VM.
https://github.com/willtobyte/carimbo
A nice thing about seeing an engine or application support Lua for scripting is that it implies Fennel can be used (and transpiled to Lua). Or at least that is highly likely unless something unusually weird is going on.
https://fennel-lang.org/
Boost.python is not the best scripting tool to be honest. So, that might affect your judgement as well.
Is Sol2 a Lua VM or just a wrapper to the standard Lua VM?
Is there a way to try out embedded Lua within the Arduino dev environment? Yeah I know, friends don't let friends, but I'm still curious.
is anyone "serious" using micropython or lua for embedded work?
I have been developing Lua-heavy embedded products as a freelancer for about 20 years now, including VoIP devices, home automation controllers, industrial routers, digital video recorders, and more. These systems typically consist of a Linux kernel, some libc implementation, the lua interpreter and a few 3d party libs support libs to help building the app. The Lua apps ranges from 30k to 100k lines of code, depending on the application. Some of these devices can be considered 'small' in 2025 terms: 8MB of flash, 64MB of ram. Lua is doing great here.
All of these products are still alive today, actively supported and making my customers good money.
Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.
For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.
I am currently working on an embedded system with 264Kb of RAM and 4Mb of flash. Do you think Lua could be used in such limited settings? I am also considering the berry scripting language [0].
[0] https://berry-lang.github.io/
I haven't worked on a system that limited (not even OpenWRT routers) since a dev board in college.
The experience I had there might be your best bet for something productive. That board came with a 'limited C-like compiler' (took a mostly complete subset of C syntax and transcribed it to ASM).
You'll probably be doing a lot of things like executing in place from ROM, and strictly managing stack and scratch pad use.
The 64MB of RAM and 8MB (I assume that's 64Mbit) of ROM allow for highly liberating things like compressed executable code copied to faster RAM, modify in place code, and enough spare RAM otherwise to use scripting languages and large buffers for work as desired.
The embedded world is really vast. If it's something safety critical, regulations won't allow it. But the regulations say nothing about all the test rigs you'll be building. IoT is another domain where people do whatever they find convenient.
Yes, we use MicroPython for medical device development up to class B.
there are thousands of products that use Lua underneath or in some capacity. I investigated LuaJIT these past few months and I think it is underrated.
Lua is just a much simpler language at heart.
Python does have the 'there should be one, preferably only one, way to do it' mantra, but to me it utterly fails at that, and is in fact a bit of a 'kitchen sink' or 'armchair' language.
That is it's strength in some ways, it's easy and approachable, and has more libraries than perhaps any other language, so you can usually get something working fairly quickly.
But it's not so suited to sparse environments. You can't easily turn a plump armchair with automatic footrests and telescoping side-tables into a plywood Eames.
Python is easy. Lua is simple.
The problem of "easy" is that it implies hidden complexity for its magic. The problem of "simple" is that it requires more work from its users.
Python also seems to have more issues with stability, in the sense that things randomly stop working when you upgrade from version 3.x to 3.x+1. Lua might not be perfect either, but at least it seems common that a platform supports a range of Lua versions instead of forcing an immediate upgrade.
With respect that sounds like marketing fluff.
You use micrpython when you have lots of horsepower and need something fairly robust on the network.
You use C/C++ if you need precise control over power, memory or CPU. Even though if you're doing network stuff its much harder to do quickly and securely. (THere might be better embedded TLS support now)
Lua is frankly just sparkling C. Sure if someone has create a bunch of libraries for you, then great, if not, you've now go to support lua toolchain, and your own microcontrollers toolchain, and port what ever control lib the manufacturer provides yourself.
Or, as this is a marketing page, pay https://realtimelogic.com/products/xedge/ to do it for you.
> You use micrpython when you have lots of horsepower
It runs on a 2350.
Cortex-M33s are decently powerful in the non-Linux embedded world. Micropython isn't competing with Linux, it is competing with bare-metal code.
the 2350 is huge compared to an STM8, or atmega.
What’s the dev experience actually like for serious Lua? I’ve only used it for some basic neovim configuration. The dynamicism and lack of type hinting in Python that was the norm when I started having to review professional code, after transitioning from pure mathematics, was a major cognitive blocker for me. With a math paper I could typically skim the first few pages to map the author’s particular symbology (if non-standard) and know exactly what was being expressed. I could never do that with untyped code.
Lua can be quite an elegant language once you get to know it well, but you can still use it like most other programming languages, it's not that weird. There are quirks like arrays starting at 1 (and all arrays being hash tables) but they don't take that long to get used to. The real strength is in the ecosystem and implementation itself, it's designed to be easily embedded into applications and there's not really much else like it. Some developers want to incorporate a scripting language into their project and get turned off by Lua's quirks and choose something else, but it usually ends up causing more problems than it was meant to solve.
On typing, there's only a few main ones you need to worry about—strings, functions, tables and numbers. I don't think it does weird things like JS where it converts between them without asking. Luau adds some type hinting if it's a big point of concern but I haven't really looked into it much.
> There are quirks like arrays starting at 1
I know it’s probably and overreaction, but this was a compete non-starter for me.
While I understand the aversion, I can't help but think that people miss out on some really cool experiences when they balk at stuff like 1-based arrays or parens in Lisp or whatever. Sure, those quirks may remain deal breakers after you've given the language a thorough try, but you may also gain super interesting new perspectives in the process.
> What’s the dev experience actually like for serious Lua
The dev experience for lua is f-ing awful.
The language is small, but not “simple”; it’s stuck in 1985.
The tooling is nearly non-existent and the stuff that does exist is a joke.
The few libraries that exist are awful and barely maintained; the maintained libraries are maintained by neckbeards with a god-complex.
The community is “reimplementing everything by hand is the right way to do it AND ALSO you’re an idiot doing it wrong” toxic. There are a million good reasons why it’s only has a foothold in nginx and Roblox territory.
It’s not a joke to say that it’s f-ing terrible all the way around.
It might not be a joke, but it is just your fucking opinion, man. Seriously, this kind of vitriol is uncalled for and only serves to make you look pathetic as fuck.
There are languages that transpile to Lua that get you things like typing…
https://typescripttolua.github.io/
I’m personally a fan of YueScript which is basically an evolution of MoonScript (but it’s not typed).
https://yuescript.org/
LuaJIT has ridiculously easy C interop.