Currently it's only targeting the ESP32 family, but the code is pretty portable. By default, it probably also needs more resources due to OS-like abstractions, allowing for multiple containers to run on parallel, etc. Obviously that also brings some nice advantages. For example, installing or updating, a new container is just a few lines of code.
We have been working on it for more than 5 years now, and it's definitely at a stage where lots of projects would benefit from it.
We found that Python isn't really designed for constrained environments. The object model, in particular, makes it hard to have fast method calls. The memory layout is also affected by the language, leading to bigger objects and a worse GC.
If you are just running a small hello world, or a number crunching loop, then both languages behave similarly. However, if you actually want to run something more consequential in production you will have an easier time with Toit.
Speed: maybe, sometimes. Of course, MicroPython makes it very easy to create modules written in C, accessible from MicroPython. So if you need extra perf you can always write a smattering of C.
Reliability: I don't see why Toit would be any better? FWIW we make medical devices using MicroPython and have tests that have run for many months with no failures. MicroPython, the language, is extremely reliable and thoroughly tested [1], though admittedly the port-specific code can be less so.
We've evaluated Toit and it has some nice features (the containerization is novel and powerful!)...but it's a quirky language with sparse peripheral support. Ultimately it's trivial for Python-familiar developers to switch across to MicroPython - a big benefit. Being constrained to the ESP32 is a limitation that many of our customers would not allow.
It advertises interpreter size and RAM requirements front and center on the homepage, so I assume that's the main draw.
I'm not super familiar with embedded Lua but I believe it to require at least an order of magnitude more RAM and codespace than this, even without float support.
For my money, Berry is still a bit heavy. On a cheap M0 I'd rather have something with about half the required memory.
Oh, they say it was inspired by Lua. So it's more like Wren I guess, but probably less performant than Wren too[1]. And less powerful than Lua since Lua metatables are half magic half genius. Still, I'd like to see a benchmark like this.
I looked at a bunch of these tiny languages, and ported several of them to the ESP32, contributed some enhancements for CircuitPython.... but eventually settled on tinyexpr, and just... Not having any data types besides numbers.
TinyExpr is very fast, it's just an expression parser, and when you pair it with a state machine engine, you can do stuff like:
"While you are in state 4, if pin Y changes, set machines.foo.state5 to 1".
Which is perfectly sufficient for most "Add a bit of configurability" tasks, I can edit behavior from my phone and make small tweaks.
Anything beyond that I would much rather just do in C++, with access to all my nice dev tools and LLMs and debuggers and linters and version control.
I really like the idea of a full language on a microcontroller, but... You usually need so many bindings and application specific functions that you always wind up needing some C++ code anyway.
I also looked at ESPHome, which is super impressive, very nice to use, but light on runtime web UI configurability, the protocol is nonstandard, and the Python client libs used to have frequent breaking changes.
Doesn't seem to have received any updates in the last 2 years. I'm wondering what the use cases are for this type of scripting in embedded systems, though?
It's still receiving maintenance from contributors, but these sort projects reach a stable maturity and stay there for years fulfilling their use case.
If you have an embedded system with a screen, say a 3d printer, it's probably nicer to write the UI in JavaScript than C.
However, now that I look at the syntax, Berry Script doesn't really look like a well designed language to me. It's like a weird mix of Lua, Python and Javascript. It's a very backwards looking (as in, it is emulating the past rather than innovating) language, where a lot of the differences only exist for the sake of being different and the more I read through the docs the more I think it looks like a bastardized Python and that I'd rather use MicroPython instead.
One benefit can be more interactive development, or interaction with the embedded device. I think various forths were used on embedded systems also because of that.
And some projects just don't require much speed and benefit from a higher level lanuage. Reading a couple of sensors over I2C every few seconds, doing some "business logic" and serving data via a http server over wifi can be simpler to achieve in higher level language and the device will be idle for the most of the time anyway.
Micropython is a nice solution in that niche.
But for some projects you do want a lower level language if not for else maybe for lower battery consumption.
Interpreted languages can be great for small code size too. Forth is especially good as it doesn't need a big runtime and the language lends itself really well to code reuse.
The repo has active development with commits from March 2025, and scripting languages like Berry enable rapid prototyping, runtime configuration changes, and user customization without reflashing firmware.
I don't use Berry (although its quite interesting), but I do use Lua in this context, and I find that putting a lot of embedded-application logic into a script is very productive - especially in the case where the VM is running and is passed a validated bytecode stream. This is quite an effective way of building sophisticated applications with embedded targets.
A microcontroller project I use has made use of JerryScript [1] instead. It uses JavaScript and is much more common and approachable to beginners. I have never heard of Berry.
I am not the author of Traquito but its primary mission is to transmit WSPR messages using 17 mW on a Raspberry Pi Pico while flying at around 40k-50k ft around the world. Running custom JavaScript to tap into optional sensors is a secondary role. So Espruino has too much overhead
Right Jerry can go as low as 64KB. But it supports ECMAScript 5.1 (real JS) and I think Berry has its own custom scripting language. I think the author of Traquito’s intent was to make it easy for students and people to add what he calls Copilot functionality to Traquito payloads without a lot of knowledge of C or custom languages. The JavaScript he supports is very easy to pick up and use for integrating sensors or reading from GPS.
I get it; but realize that it has to run the actual Traquito program which leaves little room for the JavaScript CoPilot add-on that allows for secondary running of custom user JavaScript.
Embedded GCs will never take off, waste of power. Everyone whose tried is either completely niche or out of the game. People should stop reinventing the wheel and just use C.
There's a big range of 'embedded' from CR2032-powered low-profile devices up to mains-powered logging devices with no size constraints. I agree in the first case you're unlikely to want GC but in the latter case it probably makes no difference
Given the rise of embedded linux, my last project was in Python! A complete waste of resources/memory but I get paid for results not for code
Meh. I absolutely agree that automatic memory management (and, often, any dynamic memory management, automatic or manual) on embedded is both a waste of power and problematic in terms of reliability, but that doesn't mean we should not try to improve C's rougher edges. Like, you know, dubious overflow handling rules, strict aliasing, lack of namespaces, no useable compile-time metaprogramming (when people say they hate preprocessors, they mostly mean they hate C preprocessor).
Zig seems pretty nice. And rust has some decent embedded support (though you have to be careful about what features you use i presume). A standardised rust subset could be nice.
Personally I dislike subset languages because you end up with something that’s familiar yet incompatible with half the tools and libraries you’re already familiar with.
I’d rather learn something new.
Plus once you’ve learned a few different C-like languages, it’s usually really quick learning others. Something like this looks like it would be really easy to learn if you’ve already got familiarity with C (or similar). It’s not like having to learn Lisp or Datalog if your experience is in Java or Pascal.
This Nil is not a Null, and is only used as a sentinel value to return an error value. And unlike lua, indexing into an unasigned value will not return nil, but throw an exception like index_error.
Could you clarify? I'm kind of fuzzy on those terms. From the top of the article: Cortex-M is the example, and those are what I associate as microcontrollers. Maybe naming conventions? Maybe the former is the CPU, and the latter is the CPU + the periphs, flash, ram?
It also mentions heap, which is not something I associate with microcontrollers by default, but I notice a lot of RTOS and allocators lately when I look beyond my own stuff!
The terms are fuzzier these days, but if something claims microcontroller support I expect bare metal or RTOS support and if it says microprocessor I expect a bigger OS - embedded Linux support (yocto, buildroot), standard Linux (install + package manager) or maybe one of industrial RTOS.
I’ve had a (quick) look through the docs and I can only find a REPL example running on a standard OS.
I’m sure some will argue, but I was merely quoting what I immediately saw in the docs compared to what the hn headline said.
Oh gotcha! So, A Cortex-A would be an ex of a microprocessor. Sounds like you're right that this may not be for bare metal or RTOS. Although the amount of flash and ram req will work on many MCUs. (But kind of a big overhead; e.g. the one I'm using now is 128k / 32K F/R, but I cheaped out)
A similar project: https://toitlang.org (or https://toit.io).
Currently it's only targeting the ESP32 family, but the code is pretty portable. By default, it probably also needs more resources due to OS-like abstractions, allowing for multiple containers to run on parallel, etc. Obviously that also brings some nice advantages. For example, installing or updating, a new container is just a few lines of code.
We have been working on it for more than 5 years now, and it's definitely at a stage where lots of projects would benefit from it.
Let me say that Florian and co are super helpful and responsive with code examples, fixing bugs, and have built a very dependable language in Toit.
What's the advantage over MicroPython?
Speed and reliability.
We found that Python isn't really designed for constrained environments. The object model, in particular, makes it hard to have fast method calls. The memory layout is also affected by the language, leading to bigger objects and a worse GC.
If you are just running a small hello world, or a number crunching loop, then both languages behave similarly. However, if you actually want to run something more consequential in production you will have an easier time with Toit.
Speed: maybe, sometimes. Of course, MicroPython makes it very easy to create modules written in C, accessible from MicroPython. So if you need extra perf you can always write a smattering of C.
Reliability: I don't see why Toit would be any better? FWIW we make medical devices using MicroPython and have tests that have run for many months with no failures. MicroPython, the language, is extremely reliable and thoroughly tested [1], though admittedly the port-specific code can be less so.
We've evaluated Toit and it has some nice features (the containerization is novel and powerful!)...but it's a quirky language with sparse peripheral support. Ultimately it's trivial for Python-familiar developers to switch across to MicroPython - a big benefit. Being constrained to the ESP32 is a limitation that many of our customers would not allow.
[1] See the py folder: https://micropython.org/resources/code-coverage/
Embedded Rust alternative: https://github.com/rhaiscript/rhai
This seems to have almost the exact same feature set and use-case as Lua. How does it compare in performance? I doubt it can be faster than Lua 5.5
It advertises interpreter size and RAM requirements front and center on the homepage, so I assume that's the main draw.
I'm not super familiar with embedded Lua but I believe it to require at least an order of magnitude more RAM and codespace than this, even without float support.
For my money, Berry is still a bit heavy. On a cheap M0 I'd rather have something with about half the required memory.
> The Berry interpreter-core's code size is less than 40KiB and can run on less than 4KiB heap
I did not see that on the front page. Thanks for pointing it out.
My mind shut down about 49 days ago.
Oh, they say it was inspired by Lua. So it's more like Wren I guess, but probably less performant than Wren too[1]. And less powerful than Lua since Lua metatables are half magic half genius. Still, I'd like to see a benchmark like this.
[1] https://wren.io/performance.html
Using Lua for embedded scripting is a delight
I looked at a bunch of these tiny languages, and ported several of them to the ESP32, contributed some enhancements for CircuitPython.... but eventually settled on tinyexpr, and just... Not having any data types besides numbers.
TinyExpr is very fast, it's just an expression parser, and when you pair it with a state machine engine, you can do stuff like:
"While you are in state 4, if pin Y changes, set machines.foo.state5 to 1".
Which is perfectly sufficient for most "Add a bit of configurability" tasks, I can edit behavior from my phone and make small tweaks.
Anything beyond that I would much rather just do in C++, with access to all my nice dev tools and LLMs and debuggers and linters and version control.
I really like the idea of a full language on a microcontroller, but... You usually need so many bindings and application specific functions that you always wind up needing some C++ code anyway.
I also looked at ESPHome, which is super impressive, very nice to use, but light on runtime web UI configurability, the protocol is nonstandard, and the Python client libs used to have frequent breaking changes.
https://github.com/EternityForest/ArduinoCogs
Doesn't seem to have received any updates in the last 2 years. I'm wondering what the use cases are for this type of scripting in embedded systems, though?
Running arbitrary user code in IOT systems safely like https://tasmota.github.io/docs/Berry/#rules
It's still receiving maintenance from contributors, but these sort projects reach a stable maturity and stay there for years fulfilling their use case.
Ah, yes. That makes sense.
If you have an embedded system with a screen, say a 3d printer, it's probably nicer to write the UI in JavaScript than C.
However, now that I look at the syntax, Berry Script doesn't really look like a well designed language to me. It's like a weird mix of Lua, Python and Javascript. It's a very backwards looking (as in, it is emulating the past rather than innovating) language, where a lot of the differences only exist for the sake of being different and the more I read through the docs the more I think it looks like a bastardized Python and that I'd rather use MicroPython instead.
One benefit can be more interactive development, or interaction with the embedded device. I think various forths were used on embedded systems also because of that.
And some projects just don't require much speed and benefit from a higher level lanuage. Reading a couple of sensors over I2C every few seconds, doing some "business logic" and serving data via a http server over wifi can be simpler to achieve in higher level language and the device will be idle for the most of the time anyway.
Micropython is a nice solution in that niche.
But for some projects you do want a lower level language if not for else maybe for lower battery consumption.
Interpreted languages can be great for small code size too. Forth is especially good as it doesn't need a big runtime and the language lends itself really well to code reuse.
The repo has active development with commits from March 2025, and scripting languages like Berry enable rapid prototyping, runtime configuration changes, and user customization without reflashing firmware.
>runtime configuration changes, and user customization without reflashing firmware.
This can already be done in C/cpp.
I don't use Berry (although its quite interesting), but I do use Lua in this context, and I find that putting a lot of embedded-application logic into a script is very productive - especially in the case where the VM is running and is passed a validated bytecode stream. This is quite an effective way of building sophisticated applications with embedded targets.
Adding to the list, DeviceScript, which affords running TypeScript on embedded devices:
https://microsoft.github.io/devicescript/intro
A microcontroller project I use has made use of JerryScript [1] instead. It uses JavaScript and is much more common and approachable to beginners. I have never heard of Berry.
[1] JerryScript https://jerryscript.net/
[2] Traquito: https://traquito.github.io/tracker/source/
[3] https://traquito.github.io/copilot/walkthrough/#step-3-desig...
On the other hand, I have heard of Berry, but never Jerry. I thought Espruino was the more common JS for microcontrollers?
https://www.espruino.com/
I am not the author of Traquito but its primary mission is to transmit WSPR messages using 17 mW on a Raspberry Pi Pico while flying at around 40k-50k ft around the world. Running custom JavaScript to tap into optional sensors is a secondary role. So Espruino has too much overhead
Jerry requires 64KB of RAM. Not really in the same ballpark.
Right Jerry can go as low as 64KB. But it supports ECMAScript 5.1 (real JS) and I think Berry has its own custom scripting language. I think the author of Traquito’s intent was to make it easy for students and people to add what he calls Copilot functionality to Traquito payloads without a lot of knowledge of C or custom languages. The JavaScript he supports is very easy to pick up and use for integrating sensors or reading from GPS.
FWIW, Moddable's XS gives you full JavaScript (99%+ ECMAScript 2017 compliance) and needs <32KB of free RAM. The implementation is extremely clever.
Does it? It looks like it won’t work with a RP2040
it's software, how can it not work on rp2040
Too big
The RP2040 has a whopping 264KB of RAM, which is absolutely expansive from an XS POV. It would need ~12% of that free in order to run.
A quick Google search confirms: https://moddable.com/documentation/devices/pico.php
I get it; but realize that it has to run the actual Traquito program which leaves little room for the JavaScript CoPilot add-on that allows for secondary running of custom user JavaScript.
See here
https://traquito.github.io/tracker/V1/
https://traquito.github.io/copilot/
64KB is a lot in embedded. Berry requires 4k. So there are a lot of projects that can't afford Jerry but can swing a Berry.
Embedded GCs will never take off, waste of power. Everyone whose tried is either completely niche or out of the game. People should stop reinventing the wheel and just use C.
Java is somewhat successful in the embedded sphere.
For example, every credit card chip.
There's a big range of 'embedded' from CR2032-powered low-profile devices up to mains-powered logging devices with no size constraints. I agree in the first case you're unlikely to want GC but in the latter case it probably makes no difference
Given the rise of embedded linux, my last project was in Python! A complete waste of resources/memory but I get paid for results not for code
I wouldn't exactly call Roomba niche... ;)
Meh. I absolutely agree that automatic memory management (and, often, any dynamic memory management, automatic or manual) on embedded is both a waste of power and problematic in terms of reliability, but that doesn't mean we should not try to improve C's rougher edges. Like, you know, dubious overflow handling rules, strict aliasing, lack of namespaces, no useable compile-time metaprogramming (when people say they hate preprocessors, they mostly mean they hate C preprocessor).
Zig seems pretty nice. And rust has some decent embedded support (though you have to be careful about what features you use i presume). A standardised rust subset could be nice.
Why can't this just be an embeddable subset of some other well-known language instead of a brand new language?
I've learned two dozen programming languages. I'm so tired.
Personally I dislike subset languages because you end up with something that’s familiar yet incompatible with half the tools and libraries you’re already familiar with.
I’d rather learn something new.
Plus once you’ve learned a few different C-like languages, it’s usually really quick learning others. Something like this looks like it would be really easy to learn if you’ve already got familiarity with C (or similar). It’s not like having to learn Lisp or Datalog if your experience is in Java or Pascal.
why not use Moddable's [1] xs engine [2]? it's JavaScript ...
[1] https://www.moddable.com/ [2] https://github.com/Moddable-OpenSource/moddable/tree/public/...
and it's the most conformant implementation to the latest specs of ECMAScript + of the ECMA-419 spec for js in iot
https://embedded.js.org/
Reminds me a lot of Ruby! Gorgeous.
The very first feature listed is "nil." No thanks.
Had exactly the same thought. The first thing on the list: invalid reference/null pointer exceptions, or whatever they're called here.
This Nil is not a Null, and is only used as a sentinel value to return an error value. And unlike lua, indexing into an unasigned value will not return nil, but throw an exception like index_error.
> Ideal for use in microprocessors.
Seems to be targeted at microprocessors not microcontrollers per the title.
Could you clarify? I'm kind of fuzzy on those terms. From the top of the article: Cortex-M is the example, and those are what I associate as microcontrollers. Maybe naming conventions? Maybe the former is the CPU, and the latter is the CPU + the periphs, flash, ram?
It also mentions heap, which is not something I associate with microcontrollers by default, but I notice a lot of RTOS and allocators lately when I look beyond my own stuff!
The terms are fuzzier these days, but if something claims microcontroller support I expect bare metal or RTOS support and if it says microprocessor I expect a bigger OS - embedded Linux support (yocto, buildroot), standard Linux (install + package manager) or maybe one of industrial RTOS.
I’ve had a (quick) look through the docs and I can only find a REPL example running on a standard OS.
I’m sure some will argue, but I was merely quoting what I immediately saw in the docs compared to what the hn headline said.
Oh gotcha! So, A Cortex-A would be an ex of a microprocessor. Sounds like you're right that this may not be for bare metal or RTOS. Although the amount of flash and ram req will work on many MCUs. (But kind of a big overhead; e.g. the one I'm using now is 128k / 32K F/R, but I cheaped out)
A microprocessor is a CPU. It is a holdover term from when processors got shrunk to fit on a single die.