Will this go the way of .NET micro framework and be abandoned eventually?
DeviceScript – TypeScript for Tiny IoT Devices
101–110 of 160 posts
Re: DeviceScript – TypeScript for Tiny IoT Devices
#102> 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).
Re: DeviceScript – TypeScript for Tiny IoT Devices
#103Earlier quoted context omitted.
They should integrate with Zephyr OS, as they have a good generic sensor API, with tons of device drivers and platform support.
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.
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.
Re: DeviceScript – TypeScript for Tiny IoT Devices
#104I’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 usual…
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.
Re: DeviceScript – TypeScript for Tiny IoT Devices
#105My 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
Re: DeviceScript – TypeScript for Tiny IoT Devices
#106I’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 usual…
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.
Just out of curiosity, does anyone know such an iplementation, which fully follows the standard?
Re: DeviceScript – TypeScript for Tiny IoT Devices
#107Earlier 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…
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
Isn't that just how type aliases work rather than anything to do with structural typing? That example also compiles in Haskell and Go and Kotlin.
Here's how type aliases are usually documented: "Type aliases do not introduce new types. They are equivalent to the corresponding underlying types."
The person above did have a better example of the downside: You usually want something to nominally comply with a specific interface, not structurally. i.e. Just because something happens to have an `encrypt(u8[]): u8[]` method doesn't mean you want to accept it as an argument. (Go interfaces have a similar issue.)
Re: DeviceScript – TypeScript for Tiny IoT Devices
#108Earlier quoted context omitted.
The target audience for such runtimes are teams with general software engineer skills, and less embedded skills, and little hardware skills. They are likely to weight software support (including drivers) very heavily when selecting hardware. This reduces how often the scenario you describe will come up, compared to traditional hardware development.
Yep. For example, it supports ESP32. Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
Depending on the kind of work you do, this may not be a problem.
For my day job, I use STM32/C++ because it's what the company has standardized on. For my side gig/consulting work, I've pretty much standardized on ESP32 because it's cheap, has lots of resources and good community, and I can leverage the Arduino ecosystem. It's grossly overkill for a lot of projects but no-one cares. Clients just care that you can ship fast.
My next step is moving the side gig work to MicroPython or some other higher-level language that lets me code much faster than C/C++.
Re: DeviceScript – TypeScript for Tiny IoT Devices
#109Earlier quoted context omitted.
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.
Typescript is more of "firmly" typed than strongly, in my not so humble opinion.
I guess it's beats C for IoT, but with Typescript it still feels like the S in IoT stands for Security.
Re: DeviceScript – TypeScript for Tiny IoT Devices
#110Earlier quoted context omitted.
I think having a strongly typed language is a great reason to have another interpreted language for IoT/embedded.
Typescript is more of "firmly" typed than strongly, in my not so humble opinion. I guess it's beats C for IoT, but with Typescript it still feels like the S in IoT stands for Security.
The consequences of a type unsoundness in TypeScript are typically much more benign (an exception typically) than in C (a buffer overflow, arbitrary code execution, etc.). Also the application logic is more visible in TypeScript just due to it being higher-level - there isn't so much low-level detail (ever done JSON in C?) so less chance for a mistake.