DeviceScript – TypeScript for Tiny IoT Devices(github.com) |
DeviceScript – TypeScript for Tiny IoT Devices(github.com) |
DeviceScript: TypeScript for Tiny IoT Devices - https://news.ycombinator.com/item?id=36059878 - May 2023 (101 comments)
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
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 communications are mostly handled at native speed by the VM.
2) Code size. Interpreted byte code (minus the VM) can be smaller and less redundant than native. And by adding cheap external storage, code can easily expand beyond the native program space of the micro.
3) Easy remote updates. Byte code can be received and stored without making changes to the micro's program code (no re-flashing required). It's possible to fix bugs and make changes or even completely repurpose the hardware from afar.
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.
You absolutely do when you can cut power requirements and get by with cheaper CPU/hardware. I ran a whole consulting business redesigning poorly designed devices and redoing firmware for cost reduction. How does one decide “necessary”, what is necessary in the short and long term are often not the same.
1) you get shorter battery life for slower code. Also, everything is speed critical anyways. It sucks when I’m controlling my toy robot and it’s trying to drive into the floor while doMyStuff(); has its head stuck in float math.
2) external anything is added cost to everything; adding an SPI Flash for code to otherwise done board costs, I don’t know, $2 for the chip, $0.02 for capacitors and resistors, 2-3 days to redo the board, software… can I just make it a want item for v2.0?
3) why do I have to do it wireless? Can I just snatch a prototype from test batch, wire it to debugger and leave it on a desk? Do I really have to manage these keys, and why are you going to be signing it off for release if it’s not working?
Embedded devices are not like a Nintendo Switch, it’s like Switch Joy-Cons, or even buttons on Joy-Con sometimes. They are not like nail-top autonomous Pi calculation device. Admittedly, Nintendo update Joy-Con firmware sometimes, but very rarely, and they don’t make Switch playing kids wait for X button input to finish processing. The buttons are read, sent out, and received. It just makes no sense that adding drag to real-time computing this way would help a lot.
You do get credit for using the cheapest and lowest cost MCU for the task which directly depends on performance of the code. In case of battery operated devices it is even more important.
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.
However, I suspect that the company making the ad will just list the lowest possible salary in the posting to deter real applicants from applying, hence making the greencard applications smoother.
However, don't quote me on this, since this is just my very vague knowledge on how greencard applications work. Somebody else here who knows more about this topic, please chime in to let me know if this is true.
I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
However, I heard of uPython being used in production deployments, though maybe not in millions of units.
(I'm working on DeviceScript)
Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.
I think the limitations for devicescript would probably also work for outputting reasonable amounts of C.
Instead of Rust or Zig trying to replace C++ or Java, is seems better to just integrate with it without linking through some FFI.
I'm working on some C code for some microcontroller since it was too difficult to use Rust.
I wtapped much of zephyr as well but that ones less used: https://github.com/embeddednim/nephyr
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.
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)
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.
Cost cutting in high volume electronics is crazy.
Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?
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.
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.
* 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.
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.
(26 May 2023) https://news.ycombinator.com/item?id=36079842
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."
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/a...
Though it also seems like it doesn’t use both of the LX7 cores:
> and at most one fiber runs at any given time
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.
Microsoft's MakeCode project already provides something similar, via compilation to C++, for quite some time now.
Also MakeCode compiles to ARM machine code in the browser, not C++, which is one of the things that make it hard to port.
- 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.
https://github.com/andrei-markeev/ts2c/
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
Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware
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.
Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.
Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.
I guess it's beats C for IoT, but with Typescript it still feels like the S in IoT stands for Security.
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.
Instead of ctrl+f for "professional" I suggest re-reading it
>professional TypeScript developer experience
It is about experience of sane programming environment, right?
You need to implement a safe updater (with remote protocols) on VM level. And I guess you can never upgrade the VM itself, or if you can, it adds some extra complexity, or physical access.
There also need to be some kind of signature validation for every release, which means that device needs to perform some cryptographic operations and store at least tamper-proof public keys.
Lua - an entire language that’s an off by one error.
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.
Sure, there may be problems, yet somehow the internet runs.
Coding in asm is fun, and a good skill to have for when you need it - but most of the time, you don't.
And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.
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.
For example, it supports ESP32.
Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
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++.
That was my point - the ESP32 is so versatile and cheap, it's my go-to these days for pretty much everything.
Being about to have an easy and reasonably powerful js runtime for that sounds great.
Apparently node-red also has something for esp32?
And I haven't tried it, but low.js looks cool too [1]
By having somebody else do it. Abstraction is a wonderful thing.
This is an odd statement, as if pushing along an artificially generated negative narrative. It comes across as not using or having never used what one is talking about. Therefore using hearsay and rumor ("last I heard"), which easily can come from competitors and trolls, as the basis of information versus facts.
Constructive feedback would be going to their GitHub and making suggestions, filing useful bug reports, or helping to implement some feature (for those who are really as technically skilled as they claim elsewhere).
> Has vlang managed to get past its controversies and actually deliver on its promises?
The V project is constantly delivering. This can be seen by their near weekly updates, projects on VPM, projects on Awesome V, etc...
The so-called "controversies", have much to do with competitors and trolls, as with anything else.
It might have all been fixed by now, but it is a fact that Vlang has had listed many, many, features on its homepage (without any indication that they were work in progress) that had no implementation and that had no proper prototype.
The defensiveness of Vlang supporters is not a good look.
const x: boolean | undefined | null = getValue(); const not_x: boolean = !!!y
I added TS type annotation for clarity, although could be inferred if `getValue` is typed accordingly.
return
<p>
A JSX paragraph
</p>
In TypeScript, at least, you get yelled at for this.
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)
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);
(And if you only need compile-time checks, you can make typeName nullable; {typeName?:"Dog"} != {typeName?:"Cat"})
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)
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).
type userId = string;
type subscriptionId = string;
const uid: userId = 'userA';
const sid: subscriptionId = uid; // compiler is OK with thisHere'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.)
The majority of controversy has been generated by competitors and detractors using various social media platforms to spread misinformation. To include identified troll accounts created specifically for the purpose of launching such attacks. Something like, "throwing stones and hiding their hands".
It would arguably be better to try the language out for oneself, and form one's own opinion, versus allowing known competitors and evangelists who are purposely spreading misinformation to shape one's mind. Just like it is common sense to not expect a used car dealer trying to make sales to give fair and honest opinions or assessments about competitor's cars.
> Or check what they have implemented versus promised.
Yes, totally agree that the best way is to check something out, and form one's own opinion. Also, these are free open-source languages that we are referring to. People are free to go to their GitHub and make suggestions, discuss, or join the effort to help implement whatever they feel is needed.
We could argue that all programming languages that aren't 1.0, have not delivered yet. So, with that same energy, it will be interesting to go chase around supporters of Jai, Mojo, Zig, Odin, etc... with the same rhetoric.
Vlang is "delivering" to its users, as evident by its near weekly updates, VPM, or Awesome V site. It's an open-source project and language. Developers are free to join the project to ensure "delivery of the product".
Else if they are not using said product, they don't have to worry about it. It would be bizarre for any person to be so obsessed with something one doesn't want to use, unless maybe competitors who are afraid of that language.
> ...shelling out to other executables like curl.
Vlang doesn't use curl in its modules. Everyone is free to check its source code. It has it's own such functionality, written in V. So that's looks like misinformation.
> ...defensiveness of Vlang supporters...
Didn't know about this new rule, where if one posts a response 16 days later, the other isn't allowed to make a counter point.
By the way, don't represent "all" Vlang supporters. Just giving my personal opinions, here on HN, like others are allowed to and for the languages they like.
> It might have all been fixed by now...
If one doesn't know about the thing they are talking down on ("It might"), then that looks like something very odd is going on. Doesn't make sense to worry and talk about something that one doesn't use, except again a competitor or just out to troll.
> features on its homepage (without any indication that they were work in progress) that had no implementation and that had no proper prototype...
Maybe there is confusion about what year or what time period being talked about. This is the year 2023. Perhaps what is being referred to is 2019, the first day(s) of the language being released, or mistakes on its website. Here's the thing though, its a free open-source language. Pretty sure such mistakes have happened on websites and with other languages before (especially just released ones).
Not seeing people on HN chasing down supporters of Jai, Mojo, Zig, Odin, etc... about stuff on their website from 4 and 5 years ago that nobody cares about. Furthermore, people freely choose to use, support, or donate. Not understanding being upset over what languages other people like to use, well unless...
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.
Indeed, if you add C code and that crashes it maybe harder to debug than a pure C system, however it wasn't my experience while developing DeviceScript - it was either clearly a bug in C that didn't really depend much on the bytecode, or an exception in DeviceScript which you debug just like in TypeScript.
We also support Jacdac [0] which makes it possible to put the C code on a different MCU, isolating the problem and adding traceability. (You can also run Jacdac server on the same MCU)
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).
It's too bad that this comment is buried so deep: it should be at top level. More and more often, embedded work is just like this -- the business logic is far more important than the fact that it's running on an "embedded device." And in those cases, having programmers who understand modern software development at a high level is far more useful than having programmers who are expert in C and comfortable sitting down with multiple chip datasheets for a week, writing peripheral drivers.