[geijoenr]

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?

[cprecioso]

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

[iamflimflam1]

Java was originally intended for embedded devices...

[pjc50]

It's not a bad decision for scripting provided the VM is lightweight enough. Things like "FORTH interpreter" or the old "BASIC stamp" microcontrollers. And it provides a degree of robustness vs running arbitrary binaries.

[mrguyorama]

The Apollo program went to the moon with a complex VM on top of an extremely limited physical architecture. That's actually one of the main reasons to do it, because you can implement a strictly better (in all sorts of ways) virtual machine on top of really awful hardware.

Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware

[schwartzworld]

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]

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.

[schwartzworld]

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.

[hardware2win]

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?

[suprfnk]

Easy: because TypeScript or Python are way easier to learn than C. Learning C is a long, arduous, uphill battle against arcane error messages and undefined behaviour.

Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.

[littlecranky67]

Good luck understanding things like `if(!!!c) { ... }` or why a line-break after a return statement matters in JavaScript/TypeScipt ;) JS has its own footguns and legacy baggage.

[eropple]

I've never seen `!!!` in JavaScript, and I do a lot of it. Care to share?

[littlecranky67]

Shouldn't have made an example in the if-statement as it is mostly useless there. But triple ! is very common to negate-and-convert a possibly falsy statement (undefined, null, false/true):

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.

[eropple]

I've seen `!!` and I've seen `!`, but what would `!!!` get you here that the other two don't?

[littlecranky67]

negation plus cast to boolean. See this for more info: https://stackoverflow.com/questions/21154510/the-use-of-the-...

[jve]

And line breaks after return statement? Is that true? Haven't stumbled on that one. So this is probably misinformation.

[eropple]

No, that one is true. JS automatic semicolon insertion is dumb.

   return
     <p>
       A JSX paragraph
     </p>

is a common mistake from novices; it'll return void/undefined.

In TypeScript, at least, you get yelled at for this.

[TheLoafOfBread]

How do you get that TypeScript or Python environment on the chip of your interest at the first place? How do you expose hardware interfaces without knowledge of C?

[eropple]

> How do you get that TypeScript or Python environment on the chip of your interest at the first place?

By having somebody else do it. Abstraction is a wonderful thing.

[TheLoafOfBread]

That's just kicking the can down the road. What if you are working on device which is under NDA? What if it is some exotic MCU which nobody else uses?

[jon-wood]

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

[TheLoafOfBread]

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.

[jononor]

One of they main reasons was that they had to: the cost of a more capable system was too high. In the last years that has improved drastically, and there are many usecases where the 5 USD increase in BOM needed to run JS/Python etc can be justified.

[mmoskal]

Exactly! But it's more like 1.50 USD (ESP32-C3 or RP2040 compared to say STM8).

[pjmlp]

8 and 16 bit home computing says hello.

[TheLoafOfBread]

I agree, this will mostly go nowhere. Sure when somebody will prepare you DeviceScript environment for *your* board, then you are good to go. But in 99% of cases, you will get hardware in front of you which almost certainly is not supported by DeviceScript. And now without intimate knowledge of C, how are you going to expose interfaces of that particular hardware, so you can work with those interfaces in DeviceScript? Well you won't, you need to know C first.

Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.

[jononor]

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.

[claytongulick]

Yep.

For example, it supports ESP32.

Every problem sure starts to look like a ESP32 nail if I have this tool chain available.

[HeyLaughingBoy]

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

[claytongulick]

Agree 100%

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]

[1] https://github.com/neonious/lowjs

[classified]

A VM can make all the gaping security holes portable between IOT devices.

[manmal]

I appreciate the tongue-in-cheek, but I think there‘s really the chance for better IoT security when using a VM. Those things are connected to the internet (duh) and sandboxing is probably a good idea. You obviously don’t need a VM for that, but maybe the tradeoffs are favorable.

[mrguyorama]

99% of the security issues in the IoT things are software design stupidity. Using a "safe" language or "sandboxed" VM cannot save your lightbulb when it's main loop includes "fill buffer with content from HTTP endpoint and execute it"