Live data from Hacker News

DeviceScript – TypeScript for Tiny IoT Devices

github.com

61–70 of 160 posts

Re: DeviceScript – TypeScript for Tiny IoT Devices

#61

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?

Say that to the millions of ID cards, transport cards, SIM cards, and other smart cards with a secure element that run Java (a lot of times only powered by the small current from the NFC tap).

Re: DeviceScript – TypeScript for Tiny IoT Devices

#62
post #46

Earlier quoted context omitted.

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.

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…

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

Re: DeviceScript – TypeScript for Tiny IoT Devices

#63

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

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

Re: DeviceScript – TypeScript for Tiny IoT Devices

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

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

Which is funny because there's no lack of low level programmers in my experience.

Companies just try and pay Embedded Systems Engineers and Electrical Engineers dirt compared to "Software Engineers". In the same part of NY where SWE base salaries are $160k+, they will offer $120k for the same years of experience to a EE/Embedded SWE. And these are both major companies (non-big tech) and small companies that will do this.

Of course I also see those job postings for those specific companies last a long time here. There's one going for 3 years now for a many decades old small defense contractor that's even had their CTO directly reach out to me. Meanwhile I sit pretty in my actually respectable paying embedded job that I ain't jumping ship for a paycut.

Re: DeviceScript – TypeScript for Tiny IoT Devices

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

[flagged]

TypeScript/Javascript are the modern PHP or Java of the world. It's something that people get pushed into it from school and their "first intro to programming", they often succeed through the meme of the language. But there's a subset that will struggle to actually be a "computer scientist" and pivot between languages and technologies in the long term.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#66

Earlier quoted context omitted.

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…

The debuggability is also far better I expect, as a person who has spent hours tracing some crash deep in LwIP because of a bad flag or wrong interrupt priority.

Yes.

Assuming you're working with a quality VM and drivers, development speed is also improved. A lot of low level details have already been worked out in the VM thus freeing the programmer to work at a higher level.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#67
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…

3 is a big one, I think. Using an interpreted language speeds up the development cycle to prototype, change, release, and iterate. And for some purposes it's fast and small enough, that the trade-off is worth it.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#68

Earlier quoted context omitted.

Then you probably shouldn’t use this. It’s not for you, that’s cool, move on and use whatever you’re currently using.

I am just showing you that DeviceScript/MicroPython/LUA/any other scripting language will expect from the user to know lot of C in order to be able to use its board unless they want to just run it without any input/output of data. But users want to use the scripting language because they don't know C. The whole flow is Catch-22.

I might have agreed 10 to 15 years ago when arduino was brand new and almost everything was custom.

These days... eh - pretty hard disagree with everything you've said.

Do some folks still need to know the ins & outs of the device? Sure. Will this work on every device? Nope.

Does that matter for the success of this project? Not a fucking bit.

Honestly - this looks a lot like Electron in my opinion: It gives companies a very cheap entry point into a whole realm of tooling that was previously out of bounds.

They can do it without having to hire new folks, they can prototype and run with it as far as they'd like, and then 3 years in, once the product is real and they know they have a market - they can turn around and pay someone to optimize the embedded devices for cost/power/performance/other.

The flow isn't catch-22 AT ALL. The flow is: I'm trying to do a thing that's only marginally related to the embedded device, and it's nifty that I can do that with low entry costs (both financial and knowledge).

---

By the time you are under NDA for a new device... you are established enough to be making your own decisions around tooling (basically - you are part of phase 2: optimize).

Re: DeviceScript – TypeScript for Tiny IoT Devices

#69
post #59

Earlier quoted context omitted.

The debuggability is also far better I expect, as a person who has spent hours tracing some crash deep in LwIP because of a bad flag or wrong interrupt priority.

LwIP (especially with Simcom’s SIM7000 via PPPoS underneath it) gives me PTSD. Even with decent JTAG debugging, it’s such a pain.

I think it's especially scary when most devkits come with it pre-integrated by the manufacturer, but the quality of that integration varied widely. My experience is nearly a decade out of date at this point, but when I was last going Cortex M3 stuff, I found that the integration of TI/Stellaris was excellent, and the integration on STM32 was one landmine after another— and the same held true for the USB stacks, even for stuff that should have been dirt simple like just emulating a serial port.

Re: DeviceScript – TypeScript for Tiny IoT Devices

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

[flagged]

I on the other hand started my "programming life" with C++ (because I was interested in a project written in C++) then I went to C# semi-professionally, if I was doing web it'd be with TS because of the tooling, also types help me organize my brain, and the escape hatch into YOLO land is very low in TS considering it's compiled into JS mostly, so the typesystem allows for "any" and such while still restricting things that aren't prototypes anymore.

Both C# and TS come "from the same author", so that might influence me a bit.

Post reply on HN