Low.js – Node.js for embedded devices(lowjs.org)
lowjs.org
Low.js – Node.js for embedded devices
http://www.lowjs.org
95 comments
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.
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.
That’s also absolutely massive for an embedded device. And that’s not even including code, runtime use, etc.
Note that I said devices with 32 KB of RAM. The XS7 "hello world" sample (with debugger attached) needs a total of 6 KB of RAM on ESP8266s.
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.
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 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 ...)
They won't sell it to embedded developers... They'll sell it to javascript developers who want to try out embedded development.
> 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.
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.
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.
It’s very hard to throw away decades of knowledge, libraries, and tooling.
Especially when they get the job done quite nicely.
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.
I would not want to try and sell NodeJS to an embedded developer, at least not within arms reach.
The "security issues" with IoT are a consequence of security mindset (or lack thereof), not a programming language.
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.
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.
> Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application.
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++.
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++.
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.
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).
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.
I guess exploits due to logic errors caused by lack of strong typing.
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.
Aren't there cases where low barrier to entry is a liability, not an asset?
Tessel 2 allows both JavaScript and Rust for embedded devices and they do ok.
JavaScript is very safe when it comes to things like buffer overflow and type errors. It will always try to convert to one type or another.
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).
(This is probably a naive comment. I have no idea if this would work the way I assume it would).
Duktape is just a JS engine. You still need the browser which takes 90% of the space.
The NetSurf browser (https://www.netsurf-browser.org/) uses Duktape itself and might be a good candidate :)
The NetSurf browser (https://www.netsurf-browser.org/) uses Duktape itself and might be a good candidate :)
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.
JavaScript isn't the problem. Chromium is.
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.
> 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.
I like js, but I won't sacrifice all the performance aspects in the sole name of productivity.
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.
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.
It is debatable if any (mainstream) language is designed for embedded use. C was designed for "minicomputers" (aka small mainframes), not for embedded devices.
"minicomputers" with 256kb ram and a cpu running at ~10mhz?
How would you differentiate them from today's embedded devices? ;)
How would you differentiate them from today's 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
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.
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.
The exception being micro-controllers like PICs.
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.
Not all embedded development is about PIC microcontrollers with 14KB Flash memory.
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-...
https://www.aicas.com/cms/
https://developer.android.com/things/hardware/
https://developer.microsoft.com/en-us/windows/iot
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-...
https://www.aicas.com/cms/
https://developer.android.com/things/hardware/
https://developer.microsoft.com/en-us/windows/iot
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?
Well, some of the stuff I linked to works with KB, including Cortex-Mx class devices.
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.
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.
Strange that the page talks about it being for $3 esp32 devices, but the only esp32 devices it can run on are the preflashed ones which are $12. What?
Seems like that is the chip: https://www2.mouser.com/ProductDetail/Espressif-Systems/ESP3...
Maybe you can flash them yourself somehow.
Maybe you can flash them yourself somehow.
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.
if you're ordering domestically, you'll find them more the price that you're quoting, with much quicker shipping times.
Was that with the additional 4MB PSRAM module needed for low.js?
you mean the ESP32-WROVER?
$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.
$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.
Duktape also runs in 32k (or less), but this is an implementation of the entire node.js API, not just the engine.
Cheapest boards I can find on AliExpress is $7 and up. If you just want the module then yeah $4.5.
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.
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. :)
The same advantages of you writing this post in English and not having to write it in Portuguese.
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.
Is it? have you read the average nodeJS application?
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.
[deleted]
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).
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).
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.
And C lacks a GC. Practically GCs don't fulfill the constraints of a lot of embedded projects. Even the real time GCs come at a heavy perf cost.
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.
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.
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.
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.
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 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).
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.
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.
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!
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.
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.
It's just a different world.
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.
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.
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
I'd be curious to know if something like this has any performance gains over running full Node.js in a microservice architecture under high load.
Feels like if you've got a Node service running in Docker, whether using low.js can reduce the footprint.
Feels like if you've got a Node service running in Docker, whether using low.js can reduce the footprint.
This is cool, but I don't get how to use it? I'm sold because it works on ESP8322, but I'm confused now because I have to buy the board again?
There is also JerryScript runtime by Samsung. It supports ES5.
http://jerryscript.net
http://jerryscript.net
Meh. Jamming JS into more places it has no right to be. I’m sure this’ll go well.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
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 think you’d have a hard time finding a more controversial language than nodejs.
And I personally think nodejs does a pretty poor job on less resource constrained systems, hence my disbelief that this is a good idea.
And I personally think nodejs does a pretty poor job on less resource constrained systems, hence my disbelief that this is a good idea.
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 doesn't need to be said. That's the point. Could you please stop saying it now?
[deleted]
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-...