Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DeviceScript – TypeScript for Tiny IoT Devices

github.com

Post reply on HN
Print view View original

81–90 of 160 posts

Re: DeviceScript – TypeScript for Tiny IoT Devices

#81

Post by ndiddy »

jqpabc123 wrote: post #48
nicce wrote: post #17

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.

There are a number of reasons to do this. This sort of setup typically has the VM runtime flashed into the microprocessor's program space with the interpreted byte code stored in data space --- either internal or external. 1) It is obviously not as fast as native but it is fast enough for a lot of applications. In embedded work, you don't get extra credit for being faster than necessary. Speed critical functions like…

>In embedded work, you don't get extra credit for being faster than necessary.

For battery powered devices, you absolutely do. When you're talking over a slower protocol, being able to put the processor to sleep for 95% of the time can translate to pretty massive power savings.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#82

Post by TheLoafOfBread »

claytongulick wrote: post #79
TheLoafOfBread wrote: post #76

Earlier quoted context omitted.

The problem is not higher level language. The problem is that you are essentially running dual-stack firmware with twice as complexity and twice as problems. And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.

Then I guess you'd better avoid any sort of embedded libc implementation too. Or fadecandy, or any external library. I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems. Should I just write it all in asm then? I've certainly made that choice for some projects. The point is, at some point you just want to get things done and you have to trust your tool chain.

You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe.

When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#83

Post by jononor »

biosboiii wrote: post #80

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.

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.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#84

Post by mmoskal »

tgv wrote: post #7

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

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.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#85

Post by oneplane »

jillesvangurp wrote: post #55

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.

I was thinking the same thing, just like TinyGo can target both microcontrollers and WASM.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#86

Post by esrauch »

TOGoS wrote: post #72
esrauch wrote: post #46

Earlier quoted context omitted.

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 in…

Yeah don't do that. :) Do this: interface Dog { typeName: "Dog"; woof():void } interface Cat { typeName: "Cat"; meow():void } function isDog(a:Dog|Cat) : a is Dog { return a.typeName == "Dog"; // Some casting may be required here } function f(a: Dog|Cat) { if (isDog(a)) a.woof(); else a.meow(); } let dogish : Dog = {typeName:"Dog", woof: ()=>{ console.out("Woof this is Dog")}}; f(dogish); The neat thing about TypeScr…

Sure, but opt-in nominal types that you describe is still something of a foot-gun that you have to be wary of since its easy to accidentally pass something that conforms to the structural type but violates whatever expectation. Like here's an example:

  type SpecificJsonBlob = {x: number};
  function serialize(s: SpecificJsonBlob) { return JSON.stringify(s); }
  function addOneToX(s: SpecificJsonBlob) { s.x += 1 }
  [...]
  let o = { get x() { return 1 } }
  serialize(o)
  addOneToX(o)
This compiles because the getter makes it structurally conform to the type, but the 'serialize' will surprisingly return just '{}' since JSON.stringify doesn't care about getters, and addOneToX(o) is actually just a runtime crash since it doesn't implement set x. These are runtime issues that would be precluded by the type system in a normal structural typed language.

There's obviously other cases of ergonomic benefit to structural typing (including that idiomatic JS duck-typing patterns work as you'd hope), but I think its not unreasonable for someone to feel that it's their biggest problem with typescript (as grandparent OP did).

Re: DeviceScript – TypeScript for Tiny IoT Devices

#87

Post by mmoskal »

iamflimflam1 wrote: post #18
nicce wrote: post #17

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.

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.

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)

Re: DeviceScript – TypeScript for Tiny IoT Devices

#88

Post by schwartzworld »

geijoenr wrote: post #29
schwartzworld wrote: post #22

Earlier quoted context omitted.

Making it easy for hobbyists who already know that technology to have access. Micropython has been successful, and this is an alternative to that.

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.

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.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#89

Post by Ins43b »

user_account wrote: post #56
iamflimflam1 wrote: post #23

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…

With MicroPython you can have C drivers and just do the MicroPython bindings. I do not see the benefits of having yet another interpreted IoT language and it does not make sense to do the drivers in the interpreted language itself.

I think having a strongly typed language is a great reason to have another interpreted language for IoT/embedded.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#90

Post by tentacleuno »

naikrovek wrote: post #75
nicce wrote: post #17

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.

TypeScript development on VScode is excellent (I'm told) so that would be a reason for this. Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.

It most certainly is. I've tried a lot of development solutions over the years, and always find myself coming back to VSCode. The TypeScript support is amazing.
Post reply on HN