Microsoft did something similar before (without a vm) called Static Typescript : https://www.microsoft.com/en-us/research/publication/static-...

We tried to make DeviceScript closer in semantics to real JS (prototypes etc) and easier to port. You pay with performance.

Even ES5 (the rest can be polyfilled).

The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.

Wasm also seems like a potentially better target than what we have here, which seems interpetter focused. Wasm otoh might actually be able to jit/aot compile down (which the mentioned wasm3 interpretter eskews with a list of good reasons, for anyone looking for counterarguments). And likely will have more invested in the ecosystem in doing optimizations in general.

WASM IS compiled code

> The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.

1. They said that about java too.

2. Problem is...you need to compile something to WASM, and currently a lot more somethings are compileable to native than to wasm, and i doubt this will ever change, since compiling to wasm is a strict superset of compiling to native, in terms of work involved in making a compiler. (this is not true for old esoteric architectures, but i do not see you offering me a WASM runtime for the 8051 either)

> Wasm otoh might actually be able to jit/aot compile down

You know what else does that? Any compiled language ... to native code... In fact, we "AOT" it from the start in a process we call ... compilation. Your local free copy of gcc can do this for you. Check it out.

> And likely will have more invested in the ecosystem in doing optimizations in general.

You know what else does good optimization for a given target? You local free copy of gcc. Check out the "march", "mcu", and "O" flags

Point is: I buy the use of interpreted code on IoT: so people who cannot program can still make a light blink. But as soon as you go to compiled code, might as well compile for your actual target, and not a pointless IL (which is what WASM is until you show me your HDL for a WASM cpu)

Yes, but to a VM, so the same code can run wherever there is a wasm runtime (number is growing).

Jaaaaa Vaaaaaaa

Say I run an IoT system across a variety of embedded systems. I could dynamically load small behaviors & scripts to all targets with this. User scripts could target all devices.

Your aim that native code can target everything seems to be pretty limited. A lot of languages can't or won't invest in wide micro-architectural & embedded support.

I feel lile you are confining yourself to a very very narrow position, & refusing to see possible middle grounds or uses. We needn't adopt such stark framing.

As long as there’s a C compiler for it, just use https://github.com/WebAssembly/wabt/blob/main/wasm2c/README.... or https://github.com/turbolent/w2c2

That way, you get the portability of C, the optimisation power of GCC or your favourite C compiler and the portablity and determinism of WASM! Obviously there’s some overhead but there are definitely situations where this is a good option, especially where there’s a compiler available for WASM but not for whatever obscure platform you want to use

I'm old enough to have lived the Java experience: "Write Once, Run Everywhere".

(XS is a complete ECMAScript 2020 implementation, though.)

- Tessel (closed down, domain used to be tessel.io)

- Toit Lang: https://toitlang.org/

- Moddable: https://www.moddable.com/

- Espruino: http://www.espruino.com/

- mBed tried it too: https://os.mbed.com/javascript-on-mbed/

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

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.

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.

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.

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.

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.

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.

For me, Zig and C will do it just fine.

AFAIK Java Micro Edition is mostly dead except for retrocomputing enthusiasts. Java Card is a reasonably big thing.

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

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

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.

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

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.

DFU shouldn't get used a lot, I agree, but when it's needed it's a lifesaver.

Remember also that although the language may change frequently, that doesn't mean you have to keep up with those changes.

TIL that Whirlpool used JavaScript on their ESP32 based products and shipped millions of devices

What would be an interesting starting point? I honestly don't even know what I want to build to be fair but always been interested in what the possibilities could've been with this kind of pico boards up to the raspberry (which is in a totally different range).

From what you described, using Home Assistant in the center would be the way to go (works fine on a raspberry pi, in the beginning at least)

For the devices, I mainly use zigbee sensors and lights etc. and bunch of fully DIY stuff running mostly on ESP32 with ESPHome.

For the starters, you can skip the zigbee devices all together and experiment with Home Assistant + ESPHome

https://www.nanoframework.net/

Enterprising folks have even managed to run it on the Raspberry Pi Pico...

It even works on Chrome: https://underpassapp.com/StopTheMadness/support-chrome.html

It's a runtime built on top of JerryScript, which has been pretty neat to look into as well: https://jerryscript.net/

https://www.fda.gov/medical-devices/digital-health-center-ex...

"DeviceScript is a subset of TypeScript."

We need to go deeper.

I've been using PlatformIO [1] (albeit with C++) in VScode, it would be a good DX baseline for a comparison.

[1] https://platformio.org

TypeScript is a wonderful language to develop in, and it would be awesome to be able to build TypeScript code down to small apps that don't need a JS Runtime to execute. I'd definitely be up for sacrificing some of the dynamic part of JS for being to build small native executables.

https://esphome.io