Hacker News Reader

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.

They won't sell it to embedded developers... They'll sell it to javascript developers who want to try out embedded development.

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.

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.

GCC toolchain for Xtensa has been available since day one. ESP8266 is upstream, pretty sure ESP32 is also.

Especially when they get the job done quite nicely.

> 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.

I would not want to try and sell NodeJS to an embedded developer, at least not within arms reach.