To be fair, they claim at least some subset of Node.js compatibility. Node adds a ton on top of the base JS engine, and would require more resources too.
> To be fair, they claim at least some subset of Node.js compatibility.
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.
To be fair, embedded devices come in all shapes and sizes and requirements. There are plenty of embedded devices where 2MB of RAM for the runtime is readily available and no one would bat an eye.
I don't really see the point when there are entire SBCs (Orange Pi Zero, etc) with hundreds of megabytes for less than $10 which can then run regular node. If you really are constrained to 10 MB RAM or less then there are better alternatives than node. Even the reference lua interpreter is significantly smaller than this. The Lua interpreter built with all standard Lua libraries takes 247K and the Lua library takes 421K. (See https://www.lua.org/about.html#why "Lua is small") Compatibility with node packages isn't a benefit if the packages aren't designed for devices that have 10s of megabytes.
Well, if you do mass-produced electronics, unit cost is important. And designs based on the Orange Pi Zero are far more expensive than designs based on the ESP32-WROVER.
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.
Is Javascript an appropriate language for embedded applications? Given all of the security issues with IOT, I would think a 'stricter' language (e.g., Rust or even Java) is better suited to this application.
The problem is not so much the security of Javascript itself but the craptacular state of the Javascript/Node ecosystem where pulling in random unchecked dependencies is the norm, for example. So lowering the barrier of entry to already bad IoT to Javascript programmers that have no clue whatsoever about embedded work is likely going to be a mess.
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 ...)
Also, a lot of embedded devices run on batteries. Increasing MCU power doesn’t just increase costs, it means either decreasing battery life or increased battery size, weight, cost, and charge time. This can have quite a ripple effect that might result in inferior products.
I can see this being a great way to get people interested in embedded devices through a low-friction entry into that world. Hoobyists more likely to be skilled with js than with C so getting them into the IoT world has to be as painless as possible. I see this as also a valid reason for micropython - bring the web programmers into the IoT/Maker world gently. Eventually everyone will realise when they need to do something serious that one can use these other tools to create, experiment, and refine a concept. But when it comes to building something that you want to deploy inside an elevator, car, factory, or bury 10km underground and must work for weeks/months reliably, then most everyone turns to C.
True, but there are also religious reasons against anything else that isn't Assembly or C89, when reading about experience reports about trying to move devs forward to C++ or even more up to date C versions.
And a lot of the time you don't have a choice. For example the Xtensa core in ESP32s doesn't have an upstream quality GCC or LLVM backend last time I checked.
> The problem is not so much the security of Javascript itself but the craptacular state of the Javascript/Node ecosystem where pulling in random unchecked dependencies is the norm, for example. So lowering the barrier of entry to already bad IoT to Javascript programmers that have no clue whatsoever about embedded work is likely going to be a mess.
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.
Agreed, Rust isn't going to matter over Javascript or even Visual Basic 6.0 if you're leaving port 22 open to the Internet with a username of "root" and a password of... well, just hit the enter key at the prompt, because there's no password set by default. Or exposing an anonymous TFTP server to the Internet, with a cron job running every hour to automatically flash any firmware that's dropped into there.
That's pretty much par for the course in IoT security.
IoT development in general has bad security mindset, but it does not let JS slip away from the responsibility. Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application.
Unsanitized data given to eval() is an open door for exploits, whereas lack of strong typing makes it easier for logic programming errors, due to typos or implicit conversions.
Memory corruption is just one possible attack vector.
eval() is a pretty opt-in security vuln, and there are ways of doing the equivalent in statically typed languages.
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).
What security issues do you feel that using Rust or Java would avoid? I get the impression that the underlying argument here for many is that JavaScript lowers the barrier to entry and means less experienced developers will build less secure systems.
Don't think it's necessarily the most appropriate lang, but it significantly lowers barrier to entry. One could also always use a compile-to-js lang if they want more safety e.g. TypeScript, Reason, ScalaJS, Kotlin, PureScript, etc.
If you can pick a language which is not JS, there's little point in carrying around such a resource-intensive runtime as JS requires. Consider compiling to LLVM and have a runtime statically adjusted to only carry what's actually used.
Super cool. I had never heard of Duktape before. Seems like there should be some work making Electron compatible with Duktape to reduce the memory overhead of some of our favorite Electron apps cough VScode cough Slack.
(This is probably a naive comment. I have no idea if this would work the way I assume it would).
Well first Duktape is only a Javascript engine. it is not a browser engine so there is no DOM, furthermore Duktape is not ES2015 compliant so you'd need to transpile your code to ES5. It's also debatable whether Duktape is more performant than v8 or not.
> 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.
It is naive in th form that it only looks at RAM. However the performance characteristics of duktape and efficient jit-compiling js engines will be completely different. I don’t think people would appreciate sluggish response times more than less ram usage.
It is debatable if any (mainstream) language is designed for embedded use. C was designed for "minicomputers" (aka small mainframes), not for embedded devices.
> How would you differentiate them from today's embedded devices? ;)
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
Throwing out there that PDP-11/20s were borderline running the entire manufacturing sector for a decade or so there. Parts are still super expensive because some ancient steel mill or something will buy them up as soon as they're on ebay or what have you.
But yeah, those weren't running UNIX for the most part, but probably RT-11 if their developers were sane.
Modern embedded devices are more powerful that the computer I had on high school to play Defender of the Crown on the computer club.
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.
If you have 512MB RAM you can run the atom editor on your IoT device. At that point why would anyone even care about whether the software is designed for constrained systems?
I wasn't able to find them for $3, but I did find quite a few boards ready to use on AliExpress for $4-5, as long as you're willing to take the 30 day hit on delivery.
if you're ordering domestically, you'll find them more the price that you're quoting, with much quicker shipping times.
The ESP32 version isn't open source though. It's one of those "open core" commercial projects with the commercial part being selling the dev boards/preflashed modules.
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.
It seems to me that my definition of an embedded device is different than the developer of this framework. Just because it is headless, doesn't necessarily mean it is embedded. A Linux server can be considered embedded, if that was the case.
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.
What are the advantages of this over just writing C/C++? Is there a key application/ what problem does it solve? I read the “what for” section and wasn’t convinced. :)
that's pretty fatuous. English is not easier to read/write than Portuguese when controlling for experience. js is easier to read/write even when controlling for experience.
Hacker news folks seem to be pretty negative about this. I'd definitely like to try it out. Maybe it's time to have some more options besides C on embedded devices.
There already are more options than C on embedded devices. You can run C++, Lua, Python, Ada, Lisp, Java, Forth, Rust, and dozens of others. The reason C dominates is that it's by far the most flexible, portable, and economical of these, despite its safety issues.
I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. Also C compilers were some of the most common for embedded platforms going back a few decades. Up until IoT became a buzzword, the embedded world was sort of insular and you had a lot of guys who got their start in the 80s or before. Sure, there's Forth, but that pretty much died out decades ago.
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.
Totally agree and thats what they still teach us at school in EE and CE (believe it or not). I worked a bit on embedded devices during internships and the only thing I saw is C sometimes with an API to abstract the registers (I was in the world of PIC).
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...
I never understood the attraction of PIC in the face of ARM. The ecosystem seemed so much weaker in terms of compilers, libraries, and sheer variety of parts available.
IIRC, PIC appealed to those embedded/EE guys because it was simple. It was also really cheap. You could add a tiny bit of smarts to your design for a little bit of money and effort. Those guys became well-versed in the PIC weirdness and stuck with it even though other, more traditional(i.e. 8051 based) micros came out with good features at nice price points. I don't remember a lot of cheap, easy to use options based on ARM around the time that the first PICs came out.
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 C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around.
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.
Well, that's my experience since working in embedded since '97. Remember there weren't a lot of options back then. It was the days before flash memory and you had to either use UV erasable EEPROMs or make a custom masked part. The C++ compilers were all horrible and inefficient. The debuggers barely worked. C was often your only option for a high level language, if you even had one. Some of the parts I used back then were ASM only, and if you managed to have a compiler it was so inefficient that you couldn't use it. The embedded world as I knew it was ruled by EEs. These people were barely programmers. I knew guys who would rather cut and paste code instead of make functions.
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.
I guess the CS component of EE has grown quite a lot since back then. You learn at least a solid programming base early on, and get much deeper into CS if you go down the embedded systems path. I totally agree with everything in your last two paragraphs!
Hopefully as it allows for more secure coding, but it is a struggle against the established mentality, as it has become a common theme on C++ conferences.
It is also because of the word embedded. You can call anything embedded but in our community, generally, 2MB is a rediculous amount of memory and cpu cycles are costly. C(++)/asm are very normal and people are used to that. For prototyping products we use a Forth, but I guess JS could work for that if efficient enough to try it out.
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.
I build a lot on embedded devices, including the esp8266 and esp32, and write a lot of stuff in javascript.
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).
Was reading the comments and realised it wasn't what I thought it was talking about. Very different besides name and node/js, check out this tiny local JSON database, LowDB: https://github.com/typicode/lowdb
Honestly at this point, why does “please stop shoving JS into everything, you’re fucking it all up” need to be even said? That this is even mildly controversial (or in your case, flaggable) is a sign of how far we’ve sunk.
Because anybody could say that about any programming language. Your favorite programming language could be the most hated language by any number of people. If the code can run in a system it can be useful to somebody who is more effective in a given language.
I've heard similar rage fits about Ruby and Python and yet people get plenty of work done with either one. Hell I'm sure you could hear the same damn thing about Java, but someone somewhere will find a way to shove the JVM into embedded devices too.
It's a bit sad that you have to get in the last word when disparaging Node.js along with your "DAE hate node lol"-style posts.
Remembering your contributions to the "Cycling is key to healthier cities" submission, you are clearly capable of decent discussion. But let's try to exercise some maturity across all topics.
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-...