[HN Gopher] Berry Script: lightweight embedded scripting languag...
___________________________________________________________________
Berry Script: lightweight embedded scripting language for
microcontrollers
Author : hasheddan
Score : 89 points
Date : 2025-07-05 12:13 UTC (3 days ago)
(HTM) web link (berry-lang.github.io)
(TXT) w3m dump (berry-lang.github.io)
| sagacity wrote:
| 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?
| elitepleb wrote:
| 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.
| sagacity wrote:
| Ah, yes. That makes sense.
| middayc wrote:
| 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.
| iainmerrick wrote:
| 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.
| aa-jv wrote:
| 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.
| ethan_smith wrote:
| 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.
| imtringued wrote:
| 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.
| nereye wrote:
| Adding to the list, DeviceScript, which affords running
| TypeScript on embedded devices:
|
| https://microsoft.github.io/devicescript/intro
| Alifatisk wrote:
| Reminds me a lot of Ruby! Gorgeous.
| floitsch wrote:
| 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.
| z3ugma wrote:
| 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.
| blue_pants wrote:
| What's the advantage over MicroPython?
| abdellah123 wrote:
| 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/...
| abdellah123 wrote:
| 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/
| ost-ing wrote:
| Embedded Rust alternative: https://github.com/rhaiscript/rhai
| 90s_dev wrote:
| 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
| 90s_dev wrote:
| 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
| sampullman wrote:
| 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.
| 90s_dev wrote:
| > 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.
| jonaias wrote:
| Using Lua for embedded scripting is a delight
| thebruce87m wrote:
| > Ideal for use in microprocessors.
|
| Seems to be targeted at microprocessors not microcontrollers per
| the title.
| the__alchemist wrote:
| 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!
| adastra22 wrote:
| A microprocessor is a CPU. It is a holdover term from when
| processors got shrunk to fit on a single die.
| thebruce87m wrote:
| 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.
| the__alchemist wrote:
| 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)
| eric-p7 wrote:
| 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.
| hnlmorg wrote:
| 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.
| jelder wrote:
| The very first feature listed is "nil." No thanks.
| topspin wrote:
| Had exactly the same thought. The first thing on the list:
| invalid reference/null pointer exceptions, or whatever they're
| called here.
| elitepleb wrote:
| 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.
| halfmatthalfcat wrote:
| 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.
| teamonkey wrote:
| Java is _somewhat_ successful in the embedded sphere.
| p_l wrote:
| I wouldn't exactly call Roomba niche... ;)
| tliltocatl wrote:
| 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).
| firesteelrain wrote:
| 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...
| shakna wrote:
| 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/
| firesteelrain wrote:
| I am not the author of Traquito but its primary mission is to
| transmit WSPR messages over 17 me 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
___________________________________________________________________
(page generated 2025-07-08 23:01 UTC)