3 ms·

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 case

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 3y ago
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 3y ago
  Yep. For example, it supports ESP32. Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
  - HeyLaughingBoy 3y ago
    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 3y ago
      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 https://github.com/neonious/lowjs

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 case

jononor 3y ago

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 3y ago
Yep. For example, it supports ESP32. Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
- HeyLaughingBoy 3y ago
  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 3y ago
    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 https://github.com/neonious/lowjs