6 ms·

I am always a little surprised by efforts like these coming from big companies. There have been multiple efforts in the past to put languages meant for the web

I am always a little surprised by efforts like these coming from big companies. There have been multiple efforts in the past to put languages meant for the web on small footprint devices - especially JavaScript. - Tessel (closed down, domain used to be tessel.io) - Toit Lang: https://toitlang.org/ https://toitlang.org/ - Moddable: https://www.moddable.com/ https://www.moddable.com/ - Espruino: http://www.espruino.com/ http://www.espruino.com/ - mBed tried it too: https://os.mbed.com/javascript-on-mbed/ https://os.mbed.com/javascript-on-mbed/ - https://github.com/coder-mike/microvium https://github.com/coder-mike/microvium I am sure I am missing a few here.. Note that some of these projects are over a decade old! Maybe I am the "old man yelling at the cloud" meme, but I don't see embedded developers who have to maintain a project for many many years, using a programming language that changes often.

astrobe_ 3y ago
But being able to fish in the ocean of JS devs for embedded is the dream of every manager.
- CSSer 3y ago
  And it may be a foolish one because that ocean is filled with sea monsters that even TS can’t tame.
  - wiseowise 3y ago
    I’d rather say plankton than sea monsters.
    - CSSer 3y ago
      I’ve never seen plankton sink a ship or halve its performance but sure. One can only take a metaphor so far.
- akiselev 3y ago
  Frontend developers can barely be arsed to read the short React docs once a year to catch up on any updates. There is no way in hell we're going to be able to function in an industry with thousand page data sheets and programming manuals.
  - charcircuit 3y ago
    >with thousand page data sheets and programming manuals. Why aren't those just a library? There is no way everyone deplicates the same work for interfacing with a chip for every single project that wants to use it.
    - akiselev 3y ago
      There are plenty of libraries: from low level hardware abstraction layers to high level libraries like you'd find in the Arduino ecosystem. Those closer to the former (the HALs) require more understanding thus more reading, the latter expose less of the power of the chip because they target the least common denominator. However, when you're making a mass produced piece of hardware with a $10 BOM cost and it turns out that you can save even 25 cents by using 90% of the power of a cheap chip instead of 5% of the power of an expensive chip, you're going to have to dive down into the documentation to figure out how to get every last ounce of processing power out of the cheaper chip. That usually means exploiting the unique configuration of peripherals on a chip which can't be cleanly abstracted away by a software library. My first few projects, for example, I had to work around silicon errata in the family of chips the projects had chosen: STM32F4s couldn't run both DMA channels simultaneously at max speed when outputting to different peripherals. I wouldn't have been able to figure out what's going wrong at any level of abstraction without reading the documentation. That's why I'm now in frontend instead of embedded.
    - HeyLaughingBoy 3y ago
      There are many libraries, but the peripherals on modern microcontrollers are wildly configurable and the odds of any particular library supporting every single mode possible is essentially nil. And even if it did, then the library documentation would approach the chip documentation in terms of complexity.
- ranit 3y ago
  And remains a dream far away from reality.
- mypalmike 3y ago
  /s?
- Turskarama 3y ago
  Rust (or Zig) is a much better pathway for a "user friendly" language on embedded devices than JavaScript of all things. And developers love Rust, advertise a job for an embedded Rust developer and you'll need to build a moat to keep the hordes out.
  - andsoitis 3y ago
    My best guess would be that Rust developers skew away from UI and interaction expertise.
floitsch 3y ago
Note that Toit has nothing to do with JavaScript or the Web. It was from the beginning designed to run on embedded devices.
spyremeown 3y ago
The truth is: we, actual embedded developers, much rather compile a LUA interpreter and stick it in there and be done with it.
- golergka 3y ago
  Wouldn't a modern language with a great typesystem and a huge ecosystem be nicer to work with?
  - thadt 3y ago
    Nicer from which side? Not OP, but I do like modern languages and great type systems - I’ll be the first to say that TypeScript is fantastic and maybe one of my favorite typed languages. However, embedding Lua and writing bindings for it is really easy to do. The entire thing fits in a nice, neat single directory of a few ANSI-stone-age-C files and “Just Works”. You can drop it into your codebase, write a couple of simple bindings and be off to the races in no time. And you can easily fit its world model into the model of your application. Lua’s simplicity makes it a very, very powerful tool.
  - akiselev 3y ago
    Ecosystems are as much a burden in embedded development as they are a blessing. Either you put in the time to support much of it across all your Tier 1 platforms or you punt on the problem, defeating the purpose of using a language with an ecosystem in the first place. Take Javascript, for example. Which APIs are you actually committing to support? Are you going to support the Date class? BigInt extension? Node's fs, path, and crypto libraries? The browser's local storage, indexed DB, and other high level APIs? What about setTimeout and setInterval? Or are you only supporting pure-JS libraries, forcing the user to do a manual review of each dependency they consider? A lot of microcontrollers - probably the vast majority in circulation - wouldn't have the ROM to even support most of those APIs, if they made any sense on an MCU to begin with. Look at MicroPython to see the kind of tradeoffs they have to make - it isn't pretty.
  - spyremeown 3y ago
    Other comments have put better than I could, but I'll add that what people call ecosystems nowadays is completely unthinkable in embedded. Sometimes you have critical applications and you bet you need to certify every single line of code that goes into your application. Small embedded devices are more geared towards engineering than other kinds of development, and in my opinion that's why applications work well, in comparison with the mess we have in the web nowadays, for example.
stephenboyd 3y ago
If there are no breaking changes, is it really a disadvantage for a language to add new capabilities frequently?
paulddraper 3y ago
TypeScript is popular and has static types. The others don't.
circuit10 3y ago
AssemblyScript can be used for that too, though it’s not it’s main purpose
weinzierl 3y ago
Not to forget Java ME (or whatever it is currently called). I'd argue that it is by far the most successful of all these failed attempts because it still is on many (maybe most even?) smartcards.
- ElectricalUnion 3y ago
  Java by itself was supposed to be a simple and compact language for embedded systems. AFAIK Java Micro Edition is mostly dead except for retrocomputing enthusiasts. Java Card is a reasonably big thing.
  - weinzierl 3y ago
    Right, Java Card was the thing I meant. ME was the other thing we had in the half-smart phone era.
ilyt 3y ago
I see things like MicroPython as a nice tool for prototyping hardware side rapidly (if you just need to test some SPI/I2C stuff in more complex way than i2c interface allows) and for projects simple enough that you don't ever will use most of the CPU and can afford to spend $ for wasted RAM/Flash. Like, you just want to flip some bits based on some inputs in as simple way as possible. But then eh, Arduino is easy enough for same thing...
- pseudosavant 3y ago
  I'm functionally oriented and being able to use TS instead of Arduino would be a blessing in this regard especially. I like using TS for functional coding because it forces me to really define my input/output types and helps with composability.
devjab 3y ago
I work in an investment bank that builds, operates and sells solar parks, and while the main builk of the work we do in the development department is in the fields of finance and asset management we do sometimes work with the solar inverters and similar. Being a non-tech enterprise means we're a rather small IT department in a large company that doesn't really care about tech beyond it working, as a result we've adopted Typescript as our "main" language. I've still build stuff in C and Rust, and our ML/AI employees do some of the work with Python, but over all we tend to use Typescript when and where we can because it's easier for our developers to switch and support each others if we work in the same language. If we can use a Typescript subset maintained by Microsoft on the embedded devices at the solar plants, it'll be a absolutely amazing. Regardless of what came before. Don't get me wrong. I wouldn't mind if something different took over. In many ways it would be much easier for us if we could do everything in Rust, but I don't think anyone in our team believe we'll see a realistic alternative to JavaScript on the frontend in our careers, so well...
dclowd9901 3y ago
I wouldn’t put JS on a device, but I’d sure as shit put TS on a device.
samtho 3y ago
JavaScript is the most common language for building interfaces and being event-driven. These two aspects make it uniquely suited for hardware applications. But even as a JavaScript (and specifically not TypeScript) zealot, I cannot get behind JavaScript on hardware. The reason we use C or C++ is specifically the control over the very limited memory and anything requiring a runtime or manages it’s own memory (a la garbage collection) is a non-starter. Firmware is written once and seldom updated. A node.js app is not a bad way to handle the server-side component on IoT given it’s event driven nature and access to low level constructs.
- HeyLaughingBoy 3y ago
  What do you consider by "very limited memory?" The processor I generally use for my hobby projects has 16M Flash and 4M RAM. This isn't the 80's. > Firmware is written once and seldom updated Not these days where everything must have an App as an alternate frontend. Device Firmware Update was such a frequent request that we just made it a fixed-cost line item on our quotation forms when I worked at an engineering services company. Projects where the customer didn't want DFU were far rarer than the ones that did.
  - samtho 3y ago
    My most recent project uses an STM32F030C8 which has 64Kb of flash and 8Kb of SRAM. This is actually a beefier STM32 than I usually go for but was cheaper and more available at the time of the design. I didn’t say it was never updated. Every IoT project or company I’ve worked on or with has the ability to update firmware and a lot of development effort goes into making sure that can happen. I have not worked at any place that pushed more updates per year than I can count on a single hand. Everything goes through, often manual, integration testing (ad nauseum in some cases), and field testing before it’s even considered as a release candidate. Compare this to release cadence of a CI driven development team for the web and server applications it connects to that deploys sometimes multiple times per day.
    - HeyLaughingBoy 3y ago
HeyLaughingBoy 3y ago
A (once?) popular one was BoneScript for BeagleBone. Remember also that although the language may change frequently, that doesn't mean you have to keep up with those changes.
anujdeshpande 3y ago
https://twitter.com/manas_saksena/status/1662320073661640706?s=46&t=TV_dSZnPjeouKAZ05JYdFg https://twitter.com/manas_saksena/status/1662320073661640706... TIL that Whirlpool used JavaScript on their ESP32 based products and shipped millions of devices

astrobe_ 3y ago

But being able to fish in the ocean of JS devs for embedded is the dream of every manager.

CSSer 3y ago
And it may be a foolish one because that ocean is filled with sea monsters that even TS can’t tame.
- wiseowise 3y ago
  I’d rather say plankton than sea monsters.
  - CSSer 3y ago
    I’ve never seen plankton sink a ship or halve its performance but sure. One can only take a metaphor so far.
akiselev 3y ago
Frontend developers can barely be arsed to read the short React docs once a year to catch up on any updates. There is no way in hell we're going to be able to function in an industry with thousand page data sheets and programming manuals.
- charcircuit 3y ago
  >with thousand page data sheets and programming manuals. Why aren't those just a library? There is no way everyone deplicates the same work for interfacing with a chip for every single project that wants to use it.
  - akiselev 3y ago
    There are plenty of libraries: from low level hardware abstraction layers to high level libraries like you'd find in the Arduino ecosystem. Those closer to the former (the HALs) require more understanding thus more reading, the latter expose less of the power of the chip because they target the least common denominator. However, when you're making a mass produced piece of hardware with a $10 BOM cost and it turns out that you can save even 25 cents by using 90% of the power of a cheap chip instead of 5% of the power of an expensive chip, you're going to have to dive down into the documentation to figure out how to get every last ounce of processing power out of the cheaper chip. That usually means exploiting the unique configuration of peripherals on a chip which can't be cleanly abstracted away by a software library. My first few projects, for example, I had to work around silicon errata in the family of chips the projects had chosen: STM32F4s couldn't run both DMA channels simultaneously at max speed when outputting to different peripherals. I wouldn't have been able to figure out what's going wrong at any level of abstraction without reading the documentation. That's why I'm now in frontend instead of embedded.
  - HeyLaughingBoy 3y ago
    There are many libraries, but the peripherals on modern microcontrollers are wildly configurable and the odds of any particular library supporting every single mode possible is essentially nil. And even if it did, then the library documentation would approach the chip documentation in terms of complexity.
ranit 3y ago
And remains a dream far away from reality.
mypalmike 3y ago
/s?
Turskarama 3y ago
Rust (or Zig) is a much better pathway for a "user friendly" language on embedded devices than JavaScript of all things. And developers love Rust, advertise a job for an embedded Rust developer and you'll need to build a moat to keep the hordes out.
- andsoitis 3y ago
  My best guess would be that Rust developers skew away from UI and interaction expertise.

floitsch 3y ago

Note that Toit has nothing to do with JavaScript or the Web. It was from the beginning designed to run on embedded devices.

spyremeown 3y ago

The truth is: we, actual embedded developers, much rather compile a LUA interpreter and stick it in there and be done with it.

golergka 3y ago
Wouldn't a modern language with a great typesystem and a huge ecosystem be nicer to work with?
- thadt 3y ago
  Nicer from which side? Not OP, but I do like modern languages and great type systems - I’ll be the first to say that TypeScript is fantastic and maybe one of my favorite typed languages. However, embedding Lua and writing bindings for it is really easy to do. The entire thing fits in a nice, neat single directory of a few ANSI-stone-age-C files and “Just Works”. You can drop it into your codebase, write a couple of simple bindings and be off to the races in no time. And you can easily fit its world model into the model of your application. Lua’s simplicity makes it a very, very powerful tool.
- akiselev 3y ago
  Ecosystems are as much a burden in embedded development as they are a blessing. Either you put in the time to support much of it across all your Tier 1 platforms or you punt on the problem, defeating the purpose of using a language with an ecosystem in the first place. Take Javascript, for example. Which APIs are you actually committing to support? Are you going to support the Date class? BigInt extension? Node's fs, path, and crypto libraries? The browser's local storage, indexed DB, and other high level APIs? What about setTimeout and setInterval? Or are you only supporting pure-JS libraries, forcing the user to do a manual review of each dependency they consider? A lot of microcontrollers - probably the vast majority in circulation - wouldn't have the ROM to even support most of those APIs, if they made any sense on an MCU to begin with. Look at MicroPython to see the kind of tradeoffs they have to make - it isn't pretty.
- spyremeown 3y ago
  Other comments have put better than I could, but I'll add that what people call ecosystems nowadays is completely unthinkable in embedded. Sometimes you have critical applications and you bet you need to certify every single line of code that goes into your application. Small embedded devices are more geared towards engineering than other kinds of development, and in my opinion that's why applications work well, in comparison with the mess we have in the web nowadays, for example.

stephenboyd 3y ago

If there are no breaking changes, is it really a disadvantage for a language to add new capabilities frequently?

paulddraper 3y ago

TypeScript is popular and has static types. The others don't.

circuit10 3y ago

AssemblyScript can be used for that too, though it’s not it’s main purpose

weinzierl 3y ago

Not to forget Java ME (or whatever it is currently called). I'd argue that it is by far the most successful of all these failed attempts because it still is on many (maybe most even?) smartcards.

ElectricalUnion 3y ago
Java by itself was supposed to be a simple and compact language for embedded systems. AFAIK Java Micro Edition is mostly dead except for retrocomputing enthusiasts. Java Card is a reasonably big thing.
- weinzierl 3y ago
  Right, Java Card was the thing I meant. ME was the other thing we had in the half-smart phone era.

ilyt 3y ago

I see things like MicroPython as a nice tool for prototyping hardware side rapidly (if you just need to test some SPI/I2C stuff in more complex way than i2c interface allows) and for projects simple enough that you don't ever will use most of the CPU and can afford to spend $ for wasted RAM/Flash. Like, you just want to flip some bits based on some inputs in as simple way as possible. But then eh, Arduino is easy enough for same thing...

pseudosavant 3y ago
I'm functionally oriented and being able to use TS instead of Arduino would be a blessing in this regard especially. I like using TS for functional coding because it forces me to really define my input/output types and helps with composability.

devjab 3y ago

I work in an investment bank that builds, operates and sells solar parks, and while the main builk of the work we do in the development department is in the fields of finance and asset management we do sometimes work with the solar inverters and similar. Being a non-tech enterprise means we're a rather small IT department in a large company that doesn't really care about tech beyond it working, as a result we've adopted Typescript as our "main" language. I've still build stuff in C and Rust, and our ML/AI employees do some of the work with Python, but over all we tend to use Typescript when and where we can because it's easier for our developers to switch and support each others if we work in the same language. If we can use a Typescript subset maintained by Microsoft on the embedded devices at the solar plants, it'll be a absolutely amazing. Regardless of what came before. Don't get me wrong. I wouldn't mind if something different took over. In many ways it would be much easier for us if we could do everything in Rust, but I don't think anyone in our team believe we'll see a realistic alternative to JavaScript on the frontend in our careers, so well...

dclowd9901 3y ago

I wouldn’t put JS on a device, but I’d sure as shit put TS on a device.

samtho 3y ago

JavaScript is the most common language for building interfaces and being event-driven. These two aspects make it uniquely suited for hardware applications. But even as a JavaScript (and specifically not TypeScript) zealot, I cannot get behind JavaScript on hardware. The reason we use C or C++ is specifically the control over the very limited memory and anything requiring a runtime or manages it’s own memory (a la garbage collection) is a non-starter. Firmware is written once and seldom updated. A node.js app is not a bad way to handle the server-side component on IoT given it’s event driven nature and access to low level constructs.

HeyLaughingBoy 3y ago
What do you consider by "very limited memory?" The processor I generally use for my hobby projects has 16M Flash and 4M RAM. This isn't the 80's. > Firmware is written once and seldom updated Not these days where everything must have an App as an alternate frontend. Device Firmware Update was such a frequent request that we just made it a fixed-cost line item on our quotation forms when I worked at an engineering services company. Projects where the customer didn't want DFU were far rarer than the ones that did.
- samtho 3y ago
  My most recent project uses an STM32F030C8 which has 64Kb of flash and 8Kb of SRAM. This is actually a beefier STM32 than I usually go for but was cheaper and more available at the time of the design. I didn’t say it was never updated. Every IoT project or company I’ve worked on or with has the ability to update firmware and a lot of development effort goes into making sure that can happen. I have not worked at any place that pushed more updates per year than I can count on a single hand. Everything goes through, often manual, integration testing (ad nauseum in some cases), and field testing before it’s even considered as a release candidate. Compare this to release cadence of a CI driven development team for the web and server applications it connects to that deploys sometimes multiple times per day.
  - HeyLaughingBoy 3y ago

HeyLaughingBoy 3y ago

A (once?) popular one was BoneScript for BeagleBone. Remember also that although the language may change frequently, that doesn't mean you have to keep up with those changes.

anujdeshpande 3y ago

https://twitter.com/manas_saksena/status/1662320073661640706?s=46&t=TV_dSZnPjeouKAZ05JYdFg https://twitter.com/manas_saksena/status/1662320073661640706... TIL that Whirlpool used JavaScript on their ESP32 based products and shipped millions of devices