Low.js – Node.js for embedded devices
lowjs.org
lowjs.org
Wow, that's an absolute unit of a JavaScript runtime compared to Moddable's XS7, which can run real apps on devices with as little as 32KB of RAM.
http://blog.moddable.com/blog/moddable-tech-presentation-to-...
That's very fair, thank you. XS7 is more directly comparable with the Duktape engine they're building on.
Now I'm wondering if the Low.js folks could replace Duktape with XS7 to help them not only reduce their system requirements but achieve ECMAScript 2017/ES8 compatibility to boot.
For hobbyists this also is the case, even if it is not that important: You can get boards with the ESP32-WROVER cheaper than the Orange PI Zero. And I am sure we will make low.js available for own flashing sometime in the future. We are just not there yet.
Also the fact that you need a pretty beefy MCU (=costly and not just the price of the chip itself but also the stuff required to integrate it on the board - e.g. all the RF stuff) just to be able to run Javascript on it - and cripple it in the process, because then the majority of the processing capabilities of the chip are going to be wasted on interpreting Javascript code instead of doing something useful.
I wish these guys luck if they think they can sell this software to embedded developers. There are some very good reasons why most embedded work is still done in C (not even C++!) and languages like Javascript on microcontrollers just aren't a thing - and not because they don't exist (e.g. Micropython, Forth, even Lisp ...)
Embedded already is a mess, these people can twiddle bits and bytes, but they're the most idiosyncratic and change-resistant folk among programmers. In some ways, they also have it really easy because their hardware is relatively fixed and their ecosystem evolves slowly.
> Also the fact that you need a pretty beefy MCU (=costly and not just the price of the chip itself but also the stuff required to integrate it on the board - e.g. all the RF stuff) just to be able to run Javascript on it - and cripple it in the process, because then the majority of the processing capabilities of the chip are going to be wasted on interpreting Javascript code instead of doing something useful.
Another thing embedded developers like to do is requisition "minimal" hardware even when it doesn't matter (neither in terms of price nor power) and then screw over shipped hardware on new future requirements.
A lot of these MCUs spend most of their time doing absolutely nothing, having an interpreted language there isn't necessarily a problem (though Javascript or Python aren't really ideal here). Interpreted code can drastically lower the risks associated with OTA updates.
That's pretty much par for the course in IoT security.
Explain how 'runtime interpretation + lack of strong typing' is significant for security.
JS is memory safe which makes it a more secure choice than e.g. C/C++.
Memory corruption is just one possible attack vector.
Logic errors are pretty hard to quantify, but if there're stats on vulnerabilities caused by logical errors that could only happen in languages without strong types I'd love to see them.
Meanwhile there's a whole class of vulnerabilities attributable to lack of memory safety that are pretty easily distinguished, including some of the most notorious (cloudbleed, heartbleed).
(This is probably a naive comment. I have no idea if this would work the way I assume it would).
The NetSurf browser (https://www.netsurf-browser.org/) uses Duktape itself and might be a good candidate :)
> to reduce the memory overhead of some of our favorite Electron apps cough VScode cough Slack.
are not going to take less memory with Duktape at all if the problem is sloppy programming or DOM related.
Node(nor any GC lang) is simply not designed for embedded dev. I'll gladly switch to C or Rust that are designed for this kind of work.
How would you differentiate them from today's embedded devices? ;)
Amstrad PCW 1512 vs ESP32.
If I could use high languages in MS-DOS when performance wasn't critical enough to warrant being written in Assembly, so can we in our modern embedded devices.
The exception being micro-controllers like PICs.
Intent and usage type. Minicomputers were still "general-purpose" computers, expected to run varying user code while embedded devices are more or less fixed-function.
From a more technical perspective, one difference is the expectation of (hard) real time control. While I have no doubt that some genius has put PDP-11 into industrial process control loop or something, generally UNIX (and C by extension) was not designed for real-time applications
But yeah, those weren't running UNIX for the most part, but probably RT-11 if their developers were sane.
http://www.astrobe.com/default.htm
https://www.wildernesslabs.co/
https://www.ptc.com/en/products/developer-tools/perc
http://www.microej.com/portfolio-item/28-kbyte-java-virtual-...
Genereally speaking embedded devices is a very broad area, from a tiny PIC up to a couple of MBs.
There are many factors at play and in many cases it is actually worthwhile to spend 5€ more per unit and get a better development experience.
It is a decision per case basis and not really something that we can generalise as all embedded development is like X.
Maybe you can flash them yourself somehow.
if you're ordering domestically, you'll find them more the price that you're quoting, with much quicker shipping times.
$4.50 at AliExpress if you order single.
that's the specific version of the esp32 called out on the low.js page, and according to the specs sheet is the version with the 4mb SPI accessible ram, yes.
that said, just use jerryscript (no relation), and you can run in 32k.
The ESP32 is an awesome chip, but it is a beast. Dual-core, with Bluetooth, wifi, and everything else you could think of. I wouldn't call that your typical embedded device.
But, as things get cheaper and more power efficient, my definition will be antiquated and wrong, if it isn't already.
I'm negative about this because it's hugely resource intensive when it doesn't have to be. there are much nicer ways to run javascript on a board that small (or smaller).
C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.
I talked with guys that still only coded in assembly and C was a "new" thing for them. People just don't realize that if you can save a KB of RAM and cycles of processor, you save on cost of pieces (you can use cheaper ones) and if you are to produce million of pieces thats a lot of money...
Honestly I'm not sure though. I skipped the PIC entirely. I dealt with Z8's and 68HC12s at the time(and TMS320s, but that's another story).
I think that's a pretty unfair characterization.
> C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.
I've been doing a little prototyping at work recently with micropython (not my decision), and this is one of things that frustrated me. There's also lack of good tooling compared to (embedded)C/C++, and the lack of libraries. Regular pure-Python libraries either don't run, or perform very poorly because they don't stick to the subset of the standard library that's "acceptable" in micropython. It's basically a whole different ecosystem to Python, negating a lot of the advantages of Python.
Regarding embedded Python, you have my condolences. I took a job where they use it to implement most of the system level code for a safety critical device. I was excited to do more Python until I realized what a poor choice it was for embedded. Hell, I'd rather use Java because at least you have a compiler to catch a whole class of bugs.
I'm old fashioned. If someone's life depends on it, write it in C, avoid dynamic allocation, and make heavy use of state machines. My friend works on satellite code and that's basically how it is. They don't even use an OS.
C++ has had a remarkable amount of uptake over the past few years. TI has been pushing it hard for using C++ with their DSPs.
Also, this would not pass audits (yet) in some industries. But that's not a reason to be negative; I think the footprint and calling that embedded is not very realistic atm.
You need cross-compiler support. Developers are spending much more time on compilers where the target is the same as the host architecture. Logically so! Compare GCC arm cross compiler to clang for example.
The system should be expressive enough to allow you to write function pointers to specific addresses in memory. For example if you have a binary radio stack, this might be a requirement (imho callbacks are better, but yeah). With the linker this is easy as is constraining heap, stack, etc. Where do you begin with the Python VM to do the same? It's just harder.
Support from the chipset manufacturer. If there is a HAL, it's in C. Good luck with a Rust crate pulled from somewhere random and keeping it all up to date.
Debuggers. GDB is pretty awesome in case you really need to know what's happening. You can't debug by just writing logs if you're working on the UART implementation for example. Setting breakpoints and analysing the stack is essential.
Design patterns are just different. I had a recent discussion about leaving out the destructors of a series of objects on a large mode switch (in a setup procedure) in exchange for writing the mode to FLASH, a device reset, and a few lines of startup code. The latter - the reset design paradigm - would come with a smaller binary. No management needed of all objects. A bit like rerendering the entire screen instead of only a part of it.
Hence, it's not just because people are "negative". It's really a best tool for the job kind of thing. The C (eventually C++) ecosystem is that tool.
Feels like if you've got a Node service running in Docker, whether using low.js can reduce the footprint.
And I personally think nodejs does a pretty poor job on less resource constrained systems, hence my disbelief that this is a good idea.