14 ms·

DeviceScript – TypeScript for Tiny IoT Devices

264 points by stunt 3y ago

ranguna 3y ago
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.
- pjmlp 3y ago
  Why the wait? Microsoft's MakeCode project already provides something similar, via compilation to C++, for quite some time now.
  - mmoskal 3y ago
    We're the same people who founded MakeCode. DeviceScript has a very different target audience (professional TypeScript developers vs students), is easier to port to different architectures, is more tied into VSCode, and is more compatible with JavaScript semantics (though slower). Also MakeCode compiles to ARM machine code in the browser, not C++, which is one of the things that make it hard to port.
    - pjmlp 3y ago
      I remember there was a MSR talk about compiling via C++, hence the reference.
Already__Taken 3y ago
so kind of espruino but es6 and typescript? that would be very cool.
TheLoafOfBread 3y ago
Why not just use LUA?
- dboreham 3y ago
  Because: weird language?
  - dgellow 3y ago
    Love Lua, but damn I hate the 1-based index so much, it is such a pain to adapt to it and a source of bug when implementing algorithms…
    - andrewstuart 3y ago
      I know nothing about lua but I could never touch a 1 based language. Lua - an entire language that’s an off by one error.
  - TheLoafOfBread 3y ago
    The thing is that LUA is here for quite some time and will be here when Microsoft will ends support for this experiment and it will get slowly depreciated and forgotten.
- Benjamin_Dobell 3y ago
  Because of compile-time type safety / static analysis. And I say this as the author of an IDE that bolts those features onto Lua: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis
- paulddraper 3y ago
  Static types
deleted 3y ago
[deleted]
Etheryte 3y ago
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).
tgv 3y ago
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 https://microsoft.github.io/devicescript/language
- mmoskal 3y ago
  It should about the same as uPython. There is a few more tricks we can play due to whole program compilation but I don't think we take advantage of that yet.
Benjamin_Dobell 3y ago
> == 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.
- littlecranky67 3y ago
  !=== is a typo and should probably be !==
- thangngoc89 3y ago
  Typescript has to inherit this typing madness because it’s strictly a Javascript superset. As a decade long JS developer, I avoid == and != like plague because of type castings and funny results that I don’t bother to remember.
  - criley2 3y ago
    https://eslint.org/docs/latest/rules/eqeqeq https://eslint.org/docs/latest/rules/eqeqeq !!
- mmoskal 3y ago
  Thank you! fix coming https://github.com/microsoft/devicescript/commit/a59e8aafce2b66c602c60bc82bb1bfd23298e5db https://github.com/microsoft/devicescript/commit/a59e8aafce2...
rkagerer 3y ago
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."
- girvo 3y ago
  It’s odd that the S3 isn’t supported when the S2 is the same LX7 based core and as far as ESP-IDF bring up is concerned it’s pretty much just some io_mux_reg and other definitions (at least when I ported Nesper to the S3 from the original ESP32 project) Though it also seems like it doesn’t use both of the LX7 cores: > and at most one fiber runs at any given time
- mmoskal 3y ago
  SPI is now supported (though only on ESP32 right now; PRs are welcome elswhere!), just fixed the docs. DMA is typically bundled with some other driver (like SPI). We do support ADC - there is even a funky way of exposing these nicely as Jacdac servers so they show on debugging dashboards [0] As for S3, PRs are welcome! :) [0] https://microsoft.github.io/devicescript/developer/servers/analog https://microsoft.github.io/devicescript/developer/servers/a...
andrewstuart 3y ago
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.
- black_puppydog 3y ago
  So you want structural typing, but for native? Funny, the fact that typescript is "only" structurally typed is one of my main pain points with the language. (Of course it's tons better than vanilla JS)
  - LudwigNagasena 3y ago
    What exactly do you miss? JS has built-in reflection, eg `typeof instance`, `instance.constructor.name`. Even multiple dispatch can be hacked together if you really need it, eg there is a library @arrows/multimethod.
    - esrauch 3y ago
      Those don't change that the type system is structural; the type system is actually not fully safe if you use the things you mention, eg: class Dog { woof(){} } class Cat { meow(){} } function f(a: Dog|Cat) { if (a instanceof Dog) { a.woof() } else { a.meow() } } let dogish = {woof: ()=>{}} f(dogish) This compiles because dogish is structurally a dog, the type system allows instanceof to narrow the type but "dogish instanceof Dog" is actually false, so at runtime this will crash after trying to call meow on dogish.
      - black_puppydog 3y ago
        My classic example case is actually even simpler IMHO: type userId = string; type subscriptionId = string; const uid: userId = 'userA'; const sid: subscriptionId = uid; // compiler is OK with this
nicce 3y ago
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.
- iamflimflam1 3y ago
  The same could be said for MicroPython or CircuiyPython. I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
  - mananaysiempre 3y ago
    The thing is, if you want to poke at a device interactively, your options are either Forth or (if the system is beefy enough) one of these scripting language ports; tethered C interpreters are not precisely commonplace. And while I love Forth to bits, most people will probably go the scripting-language route.
    - pjmlp 3y ago
      A whole 8 bit computing generation was able to jump into computing thanks to scripting.
  - mmoskal 3y ago
    There are some differences, but broadly correct (eg., the program is precompiled and the experience is definitely the best in VSCode; plus of course different language). However, I heard of uPython being used in production deployments, though maybe not in millions of units. (I'm working on DeviceScript)
- iampims 3y ago
  it's not C, so that's a great step towards making programming IoT more accessible.
  - 3y ago
iamflimflam1 3y ago
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/ https://microsoft.github.io/devicescript/
geijoenr 3y ago
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?
- schwartzworld 3y ago
  Making it easy for hobbyists who already know that technology to have access. Micropython has been successful, and this is an alternative to that.
  - geijoenr 3y ago
    The github project indicates "DeviceScript brings a professional TypeScript developer experience to low-resource microcontroller-based devices." If you tell me is a toy, and somebody's pet project: fine. Is all about having fun. But then don't mention "professional" in the project description.
    - hardware2win 3y ago
      Hmm? Instead of ctrl+f for "professional" I suggest re-reading it >professional TypeScript developer experience It is about experience of sane programming environment, right?
    - schwartzworld 3y ago
      It's not an experience for professional typescript development, but the experience that professional typescript developers are used to. This isn't in competition with C or C++, it's in competition with micropython. Python isn't a great language except in its ubiquity. I'd rather work in what I know, which is TS. This opens up microcontroller development to JavaScript devs of whom there are a lot of us. Types are really helpful when dealing with unfamiliar APIs. When doing embedded projects, you deal with a lot of APIs. There are the language built ins, any libraries you are using to interface with peripherals. This project opens up microcontroller development in a big way to a LOT of developers. Is it what you want to use for a commercial embedded device? I can't say. Is that the only standard? Then you should just be using C for everything, I guess. But something like a Raspberry Pi Pico or ESP32 has plenty of resources to run JavaScript while still being able to manage a weather station or automated garden or security camera or pen plotter. There are lots of applications that don't use the full power of the board.
iamflimflam1 3y ago
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/clients https://microsoft.github.io/devicescript/api/servers https://microsoft.github.io/devicescript/api/servers
- jononor 3y ago
  They should integrate with Zephyr OS, as they have a good generic sensor API, with tons of device drivers and platform support.
  - AlotOfReading 3y ago
    I wouldn't say zephyr has "tons" of drivers, except maybe in comparison to other RTOSes. It has a few drivers for each of the device types you might use, but you can't just buy random hardware without checking support the way you can with Linux. There's enough that you have examples for implementing your own drivers pretty easily though.
    - gwoplock 3y ago
      I agree with your driver assessment as someone who's used Zephyr quite a bit. If you're working with a new sensor, writing a new one is super straightforward. I don't have much experience picking sensor devices for embedded Linux, but I didn't think they had a ton of drivers for those types of devices. Bluetooth, networking, and SoCs, sure, but not so much for I2C/SPI sensors and displays and whatnot.
    - jononor 3y ago
      Tons might be stretching it. But to my knowledge there are not many alternatives for microcontrollers that have more? Hopefully one day it will be like Linux. At least they are trying to tackle the driver problem, unlike other most other RTOSes.
samwillis 3y ago
Previous discussed a couple of weeks ago: https://news.ycombinator.com/item?id=36059878 https://news.ycombinator.com/item?id=36059878 (101 comments)
- dang 3y ago
  Thanks! Macroexpanded: DeviceScript: TypeScript for Tiny IoT Devices - https://news.ycombinator.com/item?id=36059878 https://news.ycombinator.com/item?id=36059878 - May 2023 (101 comments)
NathanielBaking 3y ago
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.
- pjmlp 3y ago
  There are tons more out there, Microsoft hardly makes a difference being one more.
user_account 3y ago
Do they really need to "Embrace, extend, and extinguish" micropython?
- thawab 3y ago
  This is not the case here, because: - It's a different language/project, therefor no embrace or extending happening. - It's just 2 hackers working in microsoft, we don't have to dismiss their work because their employer actions years ago. - It's open source.
jillesvangurp 3y ago
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.
- oneplane 3y ago
  I was thinking the same thing, just like TinyGo can target both microcontrollers and WASM.
- mmoskal 3y ago
  We need to add a doc page about relationship with WASM... In short, WASM was not designed to be interpreted, and definitely not on small devices. The DeviceScript VM bytecode is designed to run directly from flash (read-only memory of which you have typically 10x more on an embedded system), with minimal overheads. Also WASM is not designed as a runtime for a dynamic language, eg., + operator would be for two i32 and what you really want for JavaScript semantics is to have a + operator that works on strings, NaN-boxed numbers, etc. As for AssemblyScript, I guess it's meant as language for small fragments of your code, not the whole application. For application you would be probably better off with Rust or similar and native compilation.
  - mmoskal 3y ago
    Promised docs here: https://microsoft.github.io/devicescript/language/runtime#why-not-web-assembly-wasm https://microsoft.github.io/devicescript/language/runtime#wh...
biosboiii 3y ago
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.
- jononor 3y ago
  There are plenty of usecases for electronics which is not high volume. And many cases where the BOM margin are not the cost driver, such as when installation/setup costs dominate. And projects where cost is secondary to thing like time-to-market, ability to integrate/customize et.c.
samtho 3y ago
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.
- chpatrick 3y ago
  I don't think there's anything inherently event-based in JavaScript the language, it's just how the browser API works. You can just as easily write busy loops.
  - over190bpm 3y ago
    Just out of curiosity, does anyone know such an iplementation, which fully follows the standard?
  - samtho 3y ago
    Sure, but that’s not the point here. With that logic, nothing is truly event-based if you can conceivably use it other ways. JavaScript was designed to interface with the DOM and had to support certain flows which is why I classify it inherently event based even if that does not meet technical requirements to call it so.
nimish 3y ago
Will this go the way of .NET micro framework and be abandoned eventually?
juancampa 3y ago
> 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).
danielEM 3y ago
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
- onimishra 3y ago
  Does such a thing exist? I would love something like that, but is it even feasible? Isn’t there a lot more you need to be aware of, to make a translation of say TS’s objects into C?
  - afiori 3y ago
    They would likely have to severely restrict the range of supported types, for example `window` is likely impossible to compile meaningfully.
  - danielEM 3y ago
    These are far from perfect, but still something: https://github.com/andrei-markeev/ts2c/ https://github.com/andrei-markeev/ts2c/ https://github.com/evanw/thinscript https://github.com/evanw/thinscript If you aim for 32 bit microcontrollers then you can go with assemblyscript to wasm and then with wasm to C transpiller
- simlevesque 3y ago
  Pure Typescript supporting all of the Ecmascript spec would have to output a lot of C to get the same results.
  - hutzlibu 3y ago
    It obviously would have to be a limited subset, like devicescript is also "just" a subset of typescript. I think the limitations for devicescript would probably also work for outputting reasonable amounts of C.
- devmunchies 3y ago
paulddraper 3y ago
(24 May 2023) https://news.ycombinator.com/item?id=36059878 https://news.ycombinator.com/item?id=36059878 (26 May 2023) https://news.ycombinator.com/item?id=36079842 https://news.ycombinator.com/item?id=36079842
eternityforest 3y ago
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.
ostenning 3y ago
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.

264 points by stunt 3y ago

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.

pjmlp 3y ago
Why the wait? Microsoft's MakeCode project already provides something similar, via compilation to C++, for quite some time now.
- mmoskal 3y ago
  We're the same people who founded MakeCode. DeviceScript has a very different target audience (professional TypeScript developers vs students), is easier to port to different architectures, is more tied into VSCode, and is more compatible with JavaScript semantics (though slower). Also MakeCode compiles to ARM machine code in the browser, not C++, which is one of the things that make it hard to port.
  - pjmlp 3y ago
    I remember there was a MSR talk about compiling via C++, hence the reference.

Already__Taken 3y ago

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

TheLoafOfBread 3y ago

Why not just use LUA?

dboreham 3y ago
Because: weird language?
- dgellow 3y ago
  Love Lua, but damn I hate the 1-based index so much, it is such a pain to adapt to it and a source of bug when implementing algorithms…
  - andrewstuart 3y ago
    I know nothing about lua but I could never touch a 1 based language. Lua - an entire language that’s an off by one error.
- TheLoafOfBread 3y ago
  The thing is that LUA is here for quite some time and will be here when Microsoft will ends support for this experiment and it will get slowly depreciated and forgotten.
Benjamin_Dobell 3y ago
Because of compile-time type safety / static analysis. And I say this as the author of an IDE that bolts those features onto Lua: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis
paulddraper 3y ago
Static types

deleted 3y ago

[deleted]

Etheryte 3y ago

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

tgv 3y ago

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 https://microsoft.github.io/devicescript/language

mmoskal 3y ago
It should about the same as uPython. There is a few more tricks we can play due to whole program compilation but I don't think we take advantage of that yet.

Benjamin_Dobell 3y ago

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

littlecranky67 3y ago
!=== is a typo and should probably be !==
thangngoc89 3y ago
Typescript has to inherit this typing madness because it’s strictly a Javascript superset. As a decade long JS developer, I avoid == and != like plague because of type castings and funny results that I don’t bother to remember.
- criley2 3y ago
  https://eslint.org/docs/latest/rules/eqeqeq https://eslint.org/docs/latest/rules/eqeqeq !!
mmoskal 3y ago
Thank you! fix coming https://github.com/microsoft/devicescript/commit/a59e8aafce2b66c602c60bc82bb1bfd23298e5db https://github.com/microsoft/devicescript/commit/a59e8aafce2...

rkagerer 3y ago

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

girvo 3y ago
It’s odd that the S3 isn’t supported when the S2 is the same LX7 based core and as far as ESP-IDF bring up is concerned it’s pretty much just some io_mux_reg and other definitions (at least when I ported Nesper to the S3 from the original ESP32 project) Though it also seems like it doesn’t use both of the LX7 cores: > and at most one fiber runs at any given time
mmoskal 3y ago
SPI is now supported (though only on ESP32 right now; PRs are welcome elswhere!), just fixed the docs. DMA is typically bundled with some other driver (like SPI). We do support ADC - there is even a funky way of exposing these nicely as Jacdac servers so they show on debugging dashboards [0] As for S3, PRs are welcome! :) [0] https://microsoft.github.io/devicescript/developer/servers/analog https://microsoft.github.io/devicescript/developer/servers/a...

andrewstuart 3y ago

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.

black_puppydog 3y ago
So you want structural typing, but for native? Funny, the fact that typescript is "only" structurally typed is one of my main pain points with the language. (Of course it's tons better than vanilla JS)
- LudwigNagasena 3y ago
  What exactly do you miss? JS has built-in reflection, eg `typeof instance`, `instance.constructor.name`. Even multiple dispatch can be hacked together if you really need it, eg there is a library @arrows/multimethod.
  - esrauch 3y ago
    Those don't change that the type system is structural; the type system is actually not fully safe if you use the things you mention, eg: class Dog { woof(){} } class Cat { meow(){} } function f(a: Dog|Cat) { if (a instanceof Dog) { a.woof() } else { a.meow() } } let dogish = {woof: ()=>{}} f(dogish) This compiles because dogish is structurally a dog, the type system allows instanceof to narrow the type but "dogish instanceof Dog" is actually false, so at runtime this will crash after trying to call meow on dogish.
    - black_puppydog 3y ago
      My classic example case is actually even simpler IMHO: type userId = string; type subscriptionId = string; const uid: userId = 'userA'; const sid: subscriptionId = uid; // compiler is OK with this

nicce 3y ago

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.

iamflimflam1 3y ago
The same could be said for MicroPython or CircuiyPython. I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
- mananaysiempre 3y ago
  The thing is, if you want to poke at a device interactively, your options are either Forth or (if the system is beefy enough) one of these scripting language ports; tethered C interpreters are not precisely commonplace. And while I love Forth to bits, most people will probably go the scripting-language route.
  - pjmlp 3y ago
    A whole 8 bit computing generation was able to jump into computing thanks to scripting.
- mmoskal 3y ago
  There are some differences, but broadly correct (eg., the program is precompiled and the experience is definitely the best in VSCode; plus of course different language). However, I heard of uPython being used in production deployments, though maybe not in millions of units. (I'm working on DeviceScript)
iampims 3y ago
it's not C, so that's a great step towards making programming IoT more accessible.
- 3y ago

iamflimflam1 3y ago

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/ https://microsoft.github.io/devicescript/

geijoenr 3y ago

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?

schwartzworld 3y ago
Making it easy for hobbyists who already know that technology to have access. Micropython has been successful, and this is an alternative to that.
- geijoenr 3y ago
  The github project indicates "DeviceScript brings a professional TypeScript developer experience to low-resource microcontroller-based devices." If you tell me is a toy, and somebody's pet project: fine. Is all about having fun. But then don't mention "professional" in the project description.
  - hardware2win 3y ago
    Hmm? Instead of ctrl+f for "professional" I suggest re-reading it >professional TypeScript developer experience It is about experience of sane programming environment, right?
  - schwartzworld 3y ago
    It's not an experience for professional typescript development, but the experience that professional typescript developers are used to. This isn't in competition with C or C++, it's in competition with micropython. Python isn't a great language except in its ubiquity. I'd rather work in what I know, which is TS. This opens up microcontroller development to JavaScript devs of whom there are a lot of us. Types are really helpful when dealing with unfamiliar APIs. When doing embedded projects, you deal with a lot of APIs. There are the language built ins, any libraries you are using to interface with peripherals. This project opens up microcontroller development in a big way to a LOT of developers. Is it what you want to use for a commercial embedded device? I can't say. Is that the only standard? Then you should just be using C for everything, I guess. But something like a Raspberry Pi Pico or ESP32 has plenty of resources to run JavaScript while still being able to manage a weather station or automated garden or security camera or pen plotter. There are lots of applications that don't use the full power of the board.

iamflimflam1 3y ago

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/clients https://microsoft.github.io/devicescript/api/servers https://microsoft.github.io/devicescript/api/servers

jononor 3y ago
They should integrate with Zephyr OS, as they have a good generic sensor API, with tons of device drivers and platform support.
- AlotOfReading 3y ago
  I wouldn't say zephyr has "tons" of drivers, except maybe in comparison to other RTOSes. It has a few drivers for each of the device types you might use, but you can't just buy random hardware without checking support the way you can with Linux. There's enough that you have examples for implementing your own drivers pretty easily though.
  - gwoplock 3y ago
    I agree with your driver assessment as someone who's used Zephyr quite a bit. If you're working with a new sensor, writing a new one is super straightforward. I don't have much experience picking sensor devices for embedded Linux, but I didn't think they had a ton of drivers for those types of devices. Bluetooth, networking, and SoCs, sure, but not so much for I2C/SPI sensors and displays and whatnot.
  - jononor 3y ago
    Tons might be stretching it. But to my knowledge there are not many alternatives for microcontrollers that have more? Hopefully one day it will be like Linux. At least they are trying to tackle the driver problem, unlike other most other RTOSes.

samwillis 3y ago

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

dang 3y ago
Thanks! Macroexpanded: DeviceScript: TypeScript for Tiny IoT Devices - https://news.ycombinator.com/item?id=36059878 https://news.ycombinator.com/item?id=36059878 - May 2023 (101 comments)

NathanielBaking 3y ago

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.

pjmlp 3y ago
There are tons more out there, Microsoft hardly makes a difference being one more.

user_account 3y ago

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

thawab 3y ago
This is not the case here, because: - It's a different language/project, therefor no embrace or extending happening. - It's just 2 hackers working in microsoft, we don't have to dismiss their work because their employer actions years ago. - It's open source.

jillesvangurp 3y ago

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.

oneplane 3y ago
I was thinking the same thing, just like TinyGo can target both microcontrollers and WASM.
mmoskal 3y ago
We need to add a doc page about relationship with WASM... In short, WASM was not designed to be interpreted, and definitely not on small devices. The DeviceScript VM bytecode is designed to run directly from flash (read-only memory of which you have typically 10x more on an embedded system), with minimal overheads. Also WASM is not designed as a runtime for a dynamic language, eg., + operator would be for two i32 and what you really want for JavaScript semantics is to have a + operator that works on strings, NaN-boxed numbers, etc. As for AssemblyScript, I guess it's meant as language for small fragments of your code, not the whole application. For application you would be probably better off with Rust or similar and native compilation.
- mmoskal 3y ago
  Promised docs here: https://microsoft.github.io/devicescript/language/runtime#why-not-web-assembly-wasm https://microsoft.github.io/devicescript/language/runtime#wh...

biosboiii 3y ago

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.

jononor 3y ago
There are plenty of usecases for electronics which is not high volume. And many cases where the BOM margin are not the cost driver, such as when installation/setup costs dominate. And projects where cost is secondary to thing like time-to-market, ability to integrate/customize et.c.

samtho 3y ago

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.

chpatrick 3y ago
I don't think there's anything inherently event-based in JavaScript the language, it's just how the browser API works. You can just as easily write busy loops.
- over190bpm 3y ago
  Just out of curiosity, does anyone know such an iplementation, which fully follows the standard?
- samtho 3y ago
  Sure, but that’s not the point here. With that logic, nothing is truly event-based if you can conceivably use it other ways. JavaScript was designed to interface with the DOM and had to support certain flows which is why I classify it inherently event based even if that does not meet technical requirements to call it so.

nimish 3y ago

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

juancampa 3y ago

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

danielEM 3y ago

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

onimishra 3y ago
Does such a thing exist? I would love something like that, but is it even feasible? Isn’t there a lot more you need to be aware of, to make a translation of say TS’s objects into C?
- afiori 3y ago
  They would likely have to severely restrict the range of supported types, for example `window` is likely impossible to compile meaningfully.
- danielEM 3y ago
  These are far from perfect, but still something: https://github.com/andrei-markeev/ts2c/ https://github.com/andrei-markeev/ts2c/ https://github.com/evanw/thinscript https://github.com/evanw/thinscript If you aim for 32 bit microcontrollers then you can go with assemblyscript to wasm and then with wasm to C transpiller
simlevesque 3y ago
Pure Typescript supporting all of the Ecmascript spec would have to output a lot of C to get the same results.
- hutzlibu 3y ago
  It obviously would have to be a limited subset, like devicescript is also "just" a subset of typescript. I think the limitations for devicescript would probably also work for outputting reasonable amounts of C.
devmunchies 3y ago

paulddraper 3y ago

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

eternityforest 3y ago

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.

ostenning 3y ago

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.