The language itself is… fine. It has some bad decisions baked into it, but what language doesn’t? And it has a pretty mature security model, which is a big help for embedded devices.
And given that so many embedded devices these days are talking to cloud services — that are probably running JS, but are at least communicating via JSON — being able to share some cross-platform code or tooling can help things go quicker and/or safer.
Edit: This is probably not a route for teams that are chronically tight on memory and choose to solve that by spending hundreds of dev-hours on optimizing code rather than adding BOM cost. But for teams that could stand to increase BOM cost as long as the savings on dev-hours make up for it… it could be an option.
JavaScript doesn’t have a few bad decisions baked into it, it’s an absolute minefield. It was made for one thing and one thing only: making simple scripts for web pages. Anything beyond that and it becomes increasingly difficult to maintain. I honesty have no idea why devs are so hellbent on using it everywhere. Putting such an unreliable dynamic language, with absolutely no safety guards when it comes to type checking and serialization, on bare metal hardware is not something I’d ever consider in good conscience. Maybe it could be used for some IoT devices, but that’s it, definitely not for something that interfaces with machinery or anything more than something like a display.
TinyGo sounds like an infinitely better pick if someone wants to use a garbage collected language on an embedded device.
Why?
The language itself is… fine. It has some bad decisions baked into it, but what language doesn’t? And it has a pretty mature security model, which is a big help for embedded devices.
And given that so many embedded devices these days are talking to cloud services — that are probably running JS, but are at least communicating via JSON — being able to share some cross-platform code or tooling can help things go quicker and/or safer.
Edit: This is probably not a route for teams that are chronically tight on memory and choose to solve that by spending hundreds of dev-hours on optimizing code rather than adding BOM cost. But for teams that could stand to increase BOM cost as long as the savings on dev-hours make up for it… it could be an option.
JavaScript doesn’t have a few bad decisions baked into it, it’s an absolute minefield. It was made for one thing and one thing only: making simple scripts for web pages. Anything beyond that and it becomes increasingly difficult to maintain. I honesty have no idea why devs are so hellbent on using it everywhere. Putting such an unreliable dynamic language, with absolutely no safety guards when it comes to type checking and serialization, on bare metal hardware is not something I’d ever consider in good conscience. Maybe it could be used for some IoT devices, but that’s it, definitely not for something that interfaces with machinery or anything more than something like a display. TinyGo sounds like an infinitely better pick if someone wants to use a garbage collected language on an embedded device.