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.
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.
I find it difficult to take any writing seriously when it uses phrases like this.
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.
While it's true you can't have multiple MicroPython interpreters running concurrently (or at least not easily; it's not that the design makes this impossible, it's just that all in all MicroPython is fairly young and development focus has been put elsewhere), it is possible to embed MicroPython. Not completely out of the box, needs some glue code etc. See for example https://github.com/micropython/micropython/tree/master/ports....
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"
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.
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.
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.
It runs on a 2350.
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.
Most of the time you have less than 1MB of ram on MCU
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.
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?
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)
https://micropython.org/resources/code-coverage/
('py' folder: 99.2% line, 88.7% branch coverage)
Testing the port-specific code has been a much more challenging problem.
Which is why in the past year or two there's been a lot of energy put in to HIL testing. There are now a few dozen boards that are automatically tested with an increasingly rich suite of hardware tests. Both the number of boards and tests are increasing rapidly.
It's not perfect but it's getting pretty darn good. If you want to help out please do reach out.
They need to test the whole ecosystem, that is the usual interaction with typical peripherals (I2C, I2S, SPI, Serial, interrupts...) and for every bug fixed there should be a unit test to make sure future changes don't cause regressions.
I had this conversation with them but they take every opportunity to justify/ask for more funding.
They are also prioritizing adding support for new chips but they quickly get eaten alive by chaos, regressions and platform fragmentation.
gdscript is so awesome
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.
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.
I know it’s probably and overreaction, but this was a compete non-starter for me.
https://typescripttolua.github.io/
I’m personally a fan of YueScript which is basically an evolution of MoonScript (but it’s not typed).
LuaJIT has ridiculously easy C interop.
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.
Even "modern" languages often don't have features like first-class functions, closures, proper tail calls, etc that Lua has had for a very long time now. LuaJIT also trades blows with JS almost certainly making it the fastest or second-fastest dynamic language around.
There's a lot to like about the language (aside from array indexes starting at 1), but I think you are right about the ecosystem and probably right about most of community.
There are a LOT of tools with embedded Lua scripting capabilities.
