6 ms·

Lua beats MicroPython for embedded devs

92 points by willhschmid 1y ago

jacknews 1y ago
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 1y ago
  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 1y ago
  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 1y ago
    Could you give some examples?
    - 3036e4 1y ago
      No, but we have a steady stream of tickets at work for scripts that must be fixed to work with a new minor python version. I thought this was common knowledge. Just look at the non-empty list of removed things in every minor release changelog. If you have enough code to maintain something is going to affect you directly or indirectly. https://docs.python.org/pl/dev/whatsnew/3.15.html https://docs.python.org/pl/dev/whatsnew/3.15.html
smohare 1y ago
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 1y ago
  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 1y ago
    > 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 1y ago
      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.
mococa 1y ago
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 https://github.com/willtobyte/carimbo
- conaclos 1y ago
  Is Sol2 a Lua VM or just a wrapper to the standard Lua VM?
  - mococa 1y ago
    It is a wrapper, in next months it will be also a luau wrapper
- triknomeister 1y ago
  Boost.python is not the best scripting tool to be honest. So, that might affect your judgement as well.
  - UncleEntity 1y ago
    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.
Palomides 1y ago
is anyone "serious" using micropython or lua for embedded work?
- qart 1y ago
  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 1y ago
  Yes, we use MicroPython for medical device development up to class B.
  - 5d41402abc4b 1y ago
    How do you handle memory fragmentation?
    - matt_trentini 1y ago
      Carefully, at least for devices with higher classifications. Using pre/early allocation helps but, more importantly, we monitor memory use over time in realistic scenarios. We've built tooling, like a memory-profiler [1] that allows us to observe memory consumption and quantify performance over time. However, it turns out that MicroPython has a simple and efficient GC - and once you eliminate code that gratuitously fragments memory it behaves quite predictably. We've tested devices running realistic scenarios for months without failure. [1] https://github.com/pi-mst/micropython-memory-profiler https://github.com/pi-mst/micropython-memory-profiler
  - xchip 1y ago
    Could you give a link to such devices?
    - matt_trentini 1y ago
rgoulter 1y ago
> [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 1y ago
  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 1y ago
  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 1y ago
  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 1y ago
    "It isn't just X, it's Y" is textbook ChatGPT.
    - zelphirkalt 1y ago
      ChatGPT must have learned that from somewhere...
KaiserPro 1y ago
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/ https://realtimelogic.com/products/xedge/ to do it for you.
- Archit3ch 1y ago
  > You use micrpython when you have lots of horsepower It runs on a 2350.
  - blackguardx 1y ago
    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 1y ago
    the 2350 is huge compared to an STM8, or atmega.
  - rasz 1y ago
    2350 with PSRAM is more powerful than top of the line 1997 PC.
analog31 1y ago
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 1y ago
  Actually I haven't heard this. Does Arduino have a bunch of controversy now?
  - analog31 1y ago
    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 1y ago
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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
  Nim is a likely a pretty good option, see https://github.com/EmbeddedNim/picostdlib/tree/master https://github.com/EmbeddedNim/picostdlib/tree/master
  - jacobgorm 1y ago
    Toit from the v8 devs is also pretty cool.
jokoon 1y ago
I dislike how the syntax of lua feels, maybe the same for its semantics gdscript is so awesome
ycombinatrix 1y ago
"Serious embedded devs" are probably using a compiled language.
- Dork1234 1y ago
  Well it is compiled into Bytecode.
jononor 1y ago
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 1y ago
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.
- stinos 1y ago
  it's not an embeddable runtime like Lua 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/embed https://github.com/micropython/micropython/tree/master/ports....
1vuio0pswjnm7 1y ago
https://pldb.io/lists/top1000.html https://pldb.io/lists/top1000.html Lua ranks higher than MicroPython in this list https://www.farginfirmware.com/home/lua-vs-micropython https://www.farginfirmware.com/home/lua-vs-micropython Github account "SkipKaczinksi" thinks Lua is generally faster https://hackaday.com/2020/11/14/micropython-on-microcontrollers/ 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-language-claims-to-be-30x-faster-than-micropython-on-esp32/ 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"
xchip 1y ago
The problem with Micropython is that they don't have unit tests for the features they implement, so they keep breaking things over and over, or fix something but brake something else.
- matt_trentini 1y ago
  Unit test coverage is exceptionally high for the interpreter, and always has been: https://micropython.org/resources/code-coverage/ 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.
  - xchip 1y ago
    Then why do they have 1300 issues open? Good luck to you but it looks like a land mine to me. They are 420 pull requests not merged, so that is a lot of disappointed developers. 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.
    - matt_trentini 1y ago
      > Then why do they have 1300 issues open? There are 420 pull requests not merged... Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs. > They need to test the whole ecosystem...and for every bug fixed there should be a unit test... Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area. > I had this conversation with them but they take every opportunity to justify/ask for more funding. Ah, I presume you're referring to this discussion? https://github.com/orgs/micropython/discussions/13436 https://github.com/orgs/micropython/discussions/13436 No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free. BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help! > They are also prioritizing adding support for new chips... That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant. > ...get eaten alive by chaos, regressions and platform fragmentation I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV. As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.

92 points by willhschmid 1y ago

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 1y ago
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 1y ago
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 1y ago
  Could you give some examples?
  - 3036e4 1y ago
    No, but we have a steady stream of tickets at work for scripts that must be fixed to work with a new minor python version. I thought this was common knowledge. Just look at the non-empty list of removed things in every minor release changelog. If you have enough code to maintain something is going to affect you directly or indirectly. https://docs.python.org/pl/dev/whatsnew/3.15.html https://docs.python.org/pl/dev/whatsnew/3.15.html

smohare 1y ago

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 1y ago
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 1y ago
  > 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 1y ago
    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.

mococa 1y ago

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 https://github.com/willtobyte/carimbo

conaclos 1y ago
Is Sol2 a Lua VM or just a wrapper to the standard Lua VM?
- mococa 1y ago
  It is a wrapper, in next months it will be also a luau wrapper
triknomeister 1y ago
Boost.python is not the best scripting tool to be honest. So, that might affect your judgement as well.
- UncleEntity 1y ago
  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.

Palomides 1y ago

is anyone "serious" using micropython or lua for embedded work?

qart 1y ago
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 1y ago
Yes, we use MicroPython for medical device development up to class B.
- 5d41402abc4b 1y ago
  How do you handle memory fragmentation?
  - matt_trentini 1y ago
    Carefully, at least for devices with higher classifications. Using pre/early allocation helps but, more importantly, we monitor memory use over time in realistic scenarios. We've built tooling, like a memory-profiler [1] that allows us to observe memory consumption and quantify performance over time. However, it turns out that MicroPython has a simple and efficient GC - and once you eliminate code that gratuitously fragments memory it behaves quite predictably. We've tested devices running realistic scenarios for months without failure. [1] https://github.com/pi-mst/micropython-memory-profiler https://github.com/pi-mst/micropython-memory-profiler
- xchip 1y ago
  Could you give a link to such devices?
  - matt_trentini 1y ago

rgoulter 1y ago

> [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 1y ago
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 1y ago
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 1y ago
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 1y ago
  "It isn't just X, it's Y" is textbook ChatGPT.
  - zelphirkalt 1y ago
    ChatGPT must have learned that from somewhere...

KaiserPro 1y ago

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/ https://realtimelogic.com/products/xedge/ to do it for you.

Archit3ch 1y ago
> You use micrpython when you have lots of horsepower It runs on a 2350.
- blackguardx 1y ago
  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 1y ago
  the 2350 is huge compared to an STM8, or atmega.
- rasz 1y ago
  2350 with PSRAM is more powerful than top of the line 1997 PC.

analog31 1y ago

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 1y ago
Actually I haven't heard this. Does Arduino have a bunch of controversy now?
- analog31 1y ago
  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 1y ago

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 1y ago

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 1y ago
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 1y ago
  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 1y ago
Nim is a likely a pretty good option, see https://github.com/EmbeddedNim/picostdlib/tree/master https://github.com/EmbeddedNim/picostdlib/tree/master
- jacobgorm 1y ago
  Toit from the v8 devs is also pretty cool.

jokoon 1y ago

I dislike how the syntax of lua feels, maybe the same for its semantics gdscript is so awesome

ycombinatrix 1y ago

"Serious embedded devs" are probably using a compiled language.

Dork1234 1y ago
Well it is compiled into Bytecode.

jononor 1y ago

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 1y ago

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.

stinos 1y ago
it's not an embeddable runtime like Lua 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/embed https://github.com/micropython/micropython/tree/master/ports....

1vuio0pswjnm7 1y ago

https://pldb.io/lists/top1000.html https://pldb.io/lists/top1000.html Lua ranks higher than MicroPython in this list https://www.farginfirmware.com/home/lua-vs-micropython https://www.farginfirmware.com/home/lua-vs-micropython Github account "SkipKaczinksi" thinks Lua is generally faster https://hackaday.com/2020/11/14/micropython-on-microcontrollers/ 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-language-claims-to-be-30x-faster-than-micropython-on-esp32/ 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"

xchip 1y ago

The problem with Micropython is that they don't have unit tests for the features they implement, so they keep breaking things over and over, or fix something but brake something else.

matt_trentini 1y ago
Unit test coverage is exceptionally high for the interpreter, and always has been: https://micropython.org/resources/code-coverage/ 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.
- xchip 1y ago
  Then why do they have 1300 issues open? Good luck to you but it looks like a land mine to me. They are 420 pull requests not merged, so that is a lot of disappointed developers. 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.
  - matt_trentini 1y ago
    > Then why do they have 1300 issues open? There are 420 pull requests not merged... Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs. > They need to test the whole ecosystem...and for every bug fixed there should be a unit test... Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area. > I had this conversation with them but they take every opportunity to justify/ask for more funding. Ah, I presume you're referring to this discussion? https://github.com/orgs/micropython/discussions/13436 https://github.com/orgs/micropython/discussions/13436 No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free. BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help! > They are also prioritizing adding support for new chips... That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant. > ...get eaten alive by chaos, regressions and platform fragmentation I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV. As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.