[HN Gopher] Lua beats MicroPython for embedded devs
___________________________________________________________________
Lua beats MicroPython for embedded devs
Author : willhschmid
Score : 66 points
Date : 2025-07-13 08:16 UTC (14 hours ago)
(HTM) web link (www.embedded.com)
(TXT) w3m dump (www.embedded.com)
| jacknews wrote:
| 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.
| qznc wrote:
| 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.
| 3036e4 wrote:
| 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.
| marky1991 wrote:
| Could you give some examples?
| smohare wrote:
| 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.
| unleaded wrote:
| 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.
| SV_BubbleTime wrote:
| > There are quirks like arrays starting at 1
|
| I know it's probably and overreaction, but this was a compete
| non-starter for me.
| Lyngbakr wrote:
| 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.
| docandrew wrote:
| Not having to put length-1 everywhere is a good thing,
| actually.
| pmarreck wrote:
| 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.
| mdkdjdnffn wrote:
| > 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.
| uamgeoalsk wrote:
| 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.
| docandrew wrote:
| nginx and Roblox and redis and nmap and neovim and cryengine
| ... the list goes on
|
| There are a LOT of tools with embedded Lua scripting
| capabilities.
| giraffe_lady wrote:
| 8 years of full time professional lua development experience
| here and unfortunately I agree with all of this. I use fennel
| when I can; it doesn't improve any of the library or tooling
| problems but it doesn't make them worse either and addresses
| several of the problems with the language semantics itself.
| delduca wrote:
| 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
| triknomeister wrote:
| Boost.python is not the best scripting tool to be honest. So,
| that might affect your judgement as well.
| UncleEntity wrote:
| I've yet to find an even decent python binding generator,
| TBH.
|
| Generally, I use pybindgen to get the basic module and then
| hack on that by hand. The main problem is most C(++)
| libraries aren't designed to interoperate with managed memory
| languages so most of the work is figuring that out. Don't get
| me wrong, I've tried to work within the binding library (with
| pybindgen at least) but the amount of work for anything even
| slightly complicated isn't really worth it.
|
| For a project with a major python API (like blender) you're
| better off crafting your own python class generator (again,
| like blended does, and even that has some major issues around
| object lifetime management). Best would be to design the
| underlying library/application with python integration in
| mind but that's not always possible if you want to include
| other libraries.
|
| I can say I did mess around with using lua as an embedded
| scripting language within an application years ago and it
| wasn't too difficult from what I remember. It was only ever a
| proof-of-concept and didn't go too far so I never ran into
| the inevitable edge case as one always does with these sorts
| of things.
| triknomeister wrote:
| That's very true actually. Boost.Python is not good, but
| the alternative then is actually doing everything ourselves
| which seems worse in short term.
| miguel_martin wrote:
| See pybind11 or nanobind
| conaclos wrote:
| Is Sol2 a Lua VM or just a wrapper to the standard Lua VM?
| delduca wrote:
| It is a wrapper, in next months it will be also a luau
| wrapper
| 3036e4 wrote:
| 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/
| Palomides wrote:
| is anyone "serious" using micropython or lua for embedded work?
| qart wrote:
| 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.
| matt_trentini wrote:
| Yes, we use MicroPython for medical device development up to
| class B.
| zevv wrote:
| 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.
| conaclos wrote:
| 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/
| mjevans wrote:
| 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.
| zevv wrote:
| That sounds like something the size of an ESP32.
|
| Assuming your flash allows XIP (execute in place) so all
| that memory is available for your lua interpreter data, you
| should at least be able to run _some_ code, but don 't
| expect to run any heavy full applications on that. I don't
| know Berry but it sounds like a better fit for the scale of
| your device.
|
| But sure, why not give it a try: Lua is usually easy to
| port to whatever platform, so just spin it up and see how
| it works for you!
| conaclos wrote:
| It is a RP2040. We plan to eventually upgrade to RP2350B.
| zevv wrote:
| Well, there you are: https://github.com/MicroLua/MicroLua
| pmarreck wrote:
| 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.
| joezydeco wrote:
| Define "serious"?
|
| Every so often I have a need for a small cheap device
| interoperating with a larger system that I'm developing. Like
| something that sits on MODBUS and does a simple task when
| signalled. I've taken the RP2040 and Pico board and spun it
| into a gizmo that can do whatever I want with Micropython, and
| it's an order of magnitude cheaper and faster than trying to
| spin it up in STMCube.
| jononor wrote:
| Just as one example, MicroPython is deployed in several
| satellites (cubesats). There are some conference talks and
| podcasts about it.
| rgoulter wrote:
| > [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.
| epcoa wrote:
| This is just an ad in a trade rag masquerading as an article or
| something. It's an ad for that Xedge Lua framework.
| stinos wrote:
| 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.
| thomasm6m6 wrote:
| 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
| AlecSchueler wrote:
| "It isn't just X, it's Y" is textbook ChatGPT.
| KaiserPro wrote:
| 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.
| Archit3ch wrote:
| > You use micrpython when you have lots of horsepower
|
| It runs on a 2350.
| blackguardx wrote:
| Cortex-M33s are decently powerful in the non-Linux embedded
| world. Micropython isn't competing with Linux, it is
| competing with bare-metal code.
| KaiserPro wrote:
| the 2350 is _huge_ compared to an STM8, or atmega.
| rasz wrote:
| 2350 with PSRAM is more powerful than top of the line 1997
| PC.
| analog31 wrote:
| 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.
| 7thaccount wrote:
| Actually I haven't heard this. Does Arduino have a bunch of
| controversy now?
| analog31 wrote:
| It evokes the "real engineers don't use it" reaction, similar
| to any tool that's perceived as being of primary interest to
| hobbyists and students.
|
| Some concerns are valid: Arduino doesn't have as much
| flexibility for digging really deep into things like pin and
| memory assignments and what happens when a microcontroller
| starts up. Also, the quality and documentation of Arduino
| support can vary from one MCU family to another.
|
| There's a concern about the quality of libraries and code.
|
| It doesn't support hardware debugging.
|
| Granted, the embedded community has good reasons for being
| conservative, especially for critical applications.
| theoutfield wrote:
| Another scripting language that I've been using in embedded
| systems with a little more memory is AngelScript. It's underrated
| in this space. It's very easy to extend and has the advantage of
| being a subset of C/C++.
| skybrian wrote:
| As a hobbyist I just use Arduino (via platformio). I don't think
| I need an interpreter of any sort for microcontrollers because
| recompiling and uploading the flash on hobbyist boards is quick
| and easy.
|
| But I'd like to try some other compiled language someday because
| I'm not a big fan of C++. Any recommendations for something that
| works well with a Raspberry Pi Pico?
| Rebelgecko wrote:
| I'm not an expert but from what I've seen Rust is one of the
| big alternatives. It's new enough to be trendy and fixed a lot
| of C++ issues whole being mature enough that the tooling is ok.
|
| I'm also intrigued by Zig. I haven't used it for anything yet
| but the language looks fun and I believe platform.io supports
| it
|
| Raspberry Pis are beefy enough that you could also get away
| with less systems-y languages. I like Kotlin. By default Kotlin
| needs a JVM but I think it's usable if you build native
| executables. However if you want to fiddle with GPIOs you might
| have to do it by manually setting things on/off in the
| filesystem (edit, sorry, just read you're using a PICO. Not
| sure how well Kotlin is supported)
| 20after4 wrote:
| The Pi Pico is a microcontroller, not a full linux-capable
| SBC. The confusion is helped by the fact that Raspberry Pi
| has a bunch of variants and almost all of them are SBCs.
| miguel_martin wrote:
| Nim is a likely a pretty good option, see
| https://github.com/EmbeddedNim/picostdlib/tree/master
| jacobgorm wrote:
| Toit from the v8 devs is also pretty cool.
| jokoon wrote:
| I dislike how the syntax of lua feels, maybe the same for its
| semantics
|
| gdscript is so awesome
| ycombinatrix wrote:
| "Serious embedded devs" are probably using a compiled language.
| jononor wrote:
| Lua is a great language, including for embedded. And I am sure
| that their Lua-based product is good also. But this article was
| not very convincing as to why it "beats MicroPython". The
| criticisms are vague or not correct. Extending MicroPython in C
| is quite easy, and one can implement third party modules in the
| same way all the official modules are made. There is build
| variable to set for including that into your custom firmware
| build - nothing particularly tricky about it. The article goes on
| to lament that popular libraries from Python world are not
| available, including numpy. But actually there is a very good
| reimplementation of numpy (and parts of scipy), called ulab.
| 10000truths wrote:
| It's important to distinguish between "embedded" as in platform,
| and "embeddable" as in "integrate into existing application".
| MicroPython is used in embedded platforms, yes, but it's not an
| _embeddable_ runtime like Lua. MicroPython is designed to
| _replace_ the traditional C runtime with a Python one. The
| expected use case is to have a minimal C shim that initializes
| MicroPython, then define the rest of your business logic as a
| MicroPython script. There 's no equivalent of lua_State that
| allows you to run multiple MicroPython interpreters concurrently
| in your program. There's no sandboxing functionality for running
| untrusted user scripts containing "while True: continue" or "oom
| = 'a'*(10**40)'. MicroPython doesn't solve the "I want rapid
| iteration with scripts in my game engine" problem, it solves the
| "I want to read the temperature sensor on my IoT board using
| Python" problem.
| 1vuio0pswjnm7 wrote:
| https://pldb.io/lists/top1000.html
|
| Lua ranks higher than MicroPython in this list
|
| https://www.farginfirmware.com/home/lua-vs-micropython
|
| Github account "SkipKaczinksi" thinks Lua is generally faster
|
| https://hackaday.com/2020/11/14/micropython-on-microcontroll...
|
| Hackaday commenter "Michael Polia" suggests Lua, smaller, faster
|
| https://www.cnx-software.com/2021/11/28/toit-open-source-lan...
|
| Toit scripting language claims to be 30x faster than MicroPython
|
| Toit founder was "responsible for initial development of V8"
___________________________________________________________________
(page generated 2025-07-13 23:01 UTC)