Previous discussed a couple of weeks ago: https://news.ycombinator.com/item?id=36059878 (101 comments)

One of the biggest challenges will be drivers for the actual hardware - at the moment it looks like they have support for SPI and for built in LEDs. But it's a big challenge to expose all the different peripherals that come with MCUs in a consistent way.

Actually, looks like they've got quite a lot of stuff done already:

https://microsoft.github.io/devicescript/api/clients https://microsoft.github.io/devicescript/api/servers

Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.

My personal opinion is that good typescript to C transpiller would do a way better job, tons of microcontrollers supported out of the box. I would be also happy to use it for desktop. With some tricks it could even support references and additional numeric data types (u8, i8 ... ) without breaking any syntax

I really want to be able to compile typescript to not javascript. Ideally to native but if it’s bytecode or whatever that’s fine I don’t care.

It’s a nightmare trying to deal with bundling and compiling and targets and different import schemes ugh.

I wish I could compile my programs it compiles all the stuff in node modules and gives me some working code.

Desperate to get away from nodejs I tried deno and bun …. neither of them are anything close to a drop in replacement for nodejs.

> == and != operators (other than == null/undefined); please use === and !===

That's a whole lot of equals signs.

Typos aside, this all looks really amazing!

Although by no means sound, the ergonomics of TypeScript's type system are phenomenal. Really glad to see additional use cases beyond traditional JS runtimes.

Main thing everyone overlooks: If you can run the same program in C on a MCU for 5 cents less, they are absolutely gonna go with that.

Cost cutting in high volume electronics is crazy.

Is really hard for me to understand how running an VM on a resource constrained device has any benefit. There is a reason why those devices run using very lightweight "OS"s like FreeRTOS and Embedded C.

Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?

This looks really promising and that's coming from someone who used to hand roll assembly for my hardware projects in uni. Since my day to day focus is elsewhere these days I need a setup that will hold my hand and hide away as many footguns as possible. I'm already familiar with Typescript so using the same language in a different environment is a win. Having that system be backed by a large company is a great boon as well, as it means there's a somewhat smaller chance of it disappearing from underneath me (Google's projects notwithstanding).

I’ve been mixed about using alternative languages or specialized runtimes on IoT devices and while I think an inherently event-driven language like JavaScript, with its first-class function as value support and widely used patterns, I’ve been of the mind lately that building firmware with these tools may be the wrong approach.

First, most IoT device behavior can be described with a finite number of actions, and usually revolves around reading and writing bits to a bus (I2C/TWI, SPI, USART, CAN) or GPIO. Hardware is only really configured once and ran forever.

I think there is a place for a hardware system that self-describes to an entity and receives a bytecode procedure for each phase of its operation. This byte code can be made small because there are not many operations to really be done and the firmware would just directly execute it and handle updates, versions, and device abstractions.

Sounds a bit similar to assemblyscript. I wonder if there's a connection between those projects. Assembly script targeting WASM on small devices might be useful.

There's a lot more information on the marketing site:

* TypeScript for IoT: The familiar syntax and tooling, all at your fingertips.

* Small Runtime: Bytecode interpreter for low power/flash/memory.

* Hardware as Services: Client/server architecture for sensors and actuators.

* Debugging: In Visual Studio Code, for embedded hardware or simulated devices.

* Simulation and Testing: Develop and test your firmware using hardware/mock sensors. CI friendly.

* Development Gateway: Prototype cloud service with device management, firmware deployment and message queues.

https://microsoft.github.io/devicescript/

Microsoft is really doing amazing with FOSS lately. The only things I see missing are some kind of filesystem. It doesn't seem quite ready to replace CircuitPython but probably will in time.

The big potential I see here is App-capable devices. That's really the missing factor with the IoT right now, the apps are separate from the device. We have to adapt everything around it to be able to talk to it, and usually you can't because it's all proprietary.

But if we had an OS and an App store, any device would work with anything.

We could actually get some good use out of Matter being IP based, if we could run apps on our smart plug.

It would be especially great for things that have a display.

I'm not sure why nobody has made an IoT OS with an app store yet, but it would/will be awesome.

> The main difference in semantics between DeviceScript and JavaScript is that DeviceScript programs run in multiple fibers (threads). In practice, this behaves like JS with async/await but without an ability to manipulate promises directly (that is fibers can only interleave at await points and at most one fiber runs at any given time).

The language seems rather complete [L], which makes me wonder: would that byte interpreter be of any use in other environments? How fast is it compared to e.g. V8 and JavaScriptCore? And to µPython?

[L] https://microsoft.github.io/devicescript/language

(24 May 2023) https://news.ycombinator.com/item?id=36059878

(26 May 2023) https://news.ycombinator.com/item?id=36079842

No ESP32-S3?

This looks great but needs a non-frictiony way to bolt together with some C or assembly code where needed. Not sure about JADAC, and wondering how hard it would be to write libraries / servers / whatever for sensors, DMA, ADC, etc.

Also note docs say "Serial, SPI, PWM are not supported yet at the DeviceScript level."

This might be suitable for dumb IoT devices that are connected to a power adapter, but as soon as you begin working with battery powered products, time critical systems, or require to reduce BoM costs, this sort of thing goes out the window.

Finally, I've been waiting for this for years now!

Now it's just a matter of continuing to expand the integrations. Will have to look at what the process looks like for creating custom integrations for existing libraries when non exist.

Do they really need to "Embrace, extend, and extinguish" micropython?

Will this go the way of .NET micro framework and be abandoned eventually?

so kind of espruino but es6 and typescript? that would be very cool.

Why not just use LUA?

Microsoft has a long history of fracturing programming language markets. It's not so much that it is a bad idea, more that it divides an already healthy market. There is MicroPython, Arduino, and Node-RED not to mention all of the C/C++ based systems out there: mBed, Zephyr, and RIOT OS. Another addition is not helpful.