We prototype everything in a higher level language first and then 'translate it' (manually) to something that fits the production platform.

For instance, for our current iteration of our product, we created a first 'visual prototype' with Flutter (this contains all algorithms and data-structures already to almost translate 1-1 to C++ and C/asm), then we worked down to C++ (next time we are going to try Rust for this phase) on a powerful mcu but with the (mostly) identical peripherals as the final product. Final step (currently ongoing) is the translation to C/asm to fit the MCU's we use (2mhz/24kb).

Over the decades we have seen that this process is the fastest and least bug prone way. We already think in low level structures and algorithm implementations when coding the high level 'visual' model (or sales/investor pitch model often) (which used to be Java desktop applications, but now with smart phones it's far closer to what the end product will be) so that when we move down towards production components (which means basically as cheap as possible BOM for 1m+ runs; every cent counts, also, we have never had the experience where, after the fact, we encountered this common thing in software; 'people are more expensive than hardware'. Even for a few cents difference we can pay more people than we needed. But yes, that means optimising every byte...), we don't have to spend that much time on those. It's just on hardware specific stuff for the C++ 'big' mcu version and then it's just bit-fiddling/optimising for the lowest level version.

Yes and much more straight forward to interface with hardware - but also requires some level of exp with said low level languages.

Arduino did a lot to reduce barrier to entry to the uC world - but even that requires you to understand a little of how C++ works once you move beyond blinky.

These (micropython, this project, Lua ) etc lower the barrier to entry even further. The trade off of course is how well they run and how much of the hardware is exposed (register manipulation etc) if you want to get to it...

I'm not a fan of Javascript on microcontollers, but you can't ask that question without asking "Okay, so which language?"

Your really small language alternatives:

1) BASIC--Okay, but not exactly mainstream nowadays

2) Tcl--My favorite on small devices, but it's more like a Lisp than a mainstream language so there's a barrier

3) A Scheme/Lisp--again sufficiently different that it presents a barrier to entry

4) Forth--For those who don't find Lisp different enough

5) Lua--1-based in a 0-based world AND you have to add so many "extensions" that its no longer "small" when you finish.

And ... ?

As opposed to:

A) Espruino aka Javascript--everybody and their dog can put together 10 lines of Javascript and make it work. Resources are everywhere. You're probably not building anything large enough to activate most of Javascripts negatives (generally related to concurrency and building in the large)

B) Micropython -- a lot of people with scientific background can throw together a couple dozen lines of Python and connect to something in their lab. Lots of resources and help available.

MY problem is that I would like something like one of these languages but that runs in <4K RAM and <16K FLASH. I want an actual small language that runs in something smaller than an Apple IIe, thanks.

Most micro-controllers are more powerful than the PCs I used with MS-DOS on, plenty of juice on those 80x86 with 640 KB memory for high level languages.

Naturally anything performance critical back then was written in pure Assembly, but plenty of stuff was achievable with Basic, Pascal, C, Lisp, Clipper, Prolog and plenty of other stuff.

First profit from productivity in a high level language, then optimize within its capabilities, and if that still isn't enough than dive into Assembly.

Of course. But efficiency is not the only important thing in the world.

You can explore the world from different perspectives, not just from one.

Lisp was for a long time a very inefficient language, but also extremely important.

The users of early Lisp did not care so much about efficiency, they were mainly academics after all and someone else did buy the machines they used(they did cost hundreds of thousands of dollars each).

They cared about things like reusability of code, being easy to understand, not making mistakes or just exploring the new world of computers.

They invented flow control directives like "cond" and later "if", "while"..., functions, lambdas, macros, program evaluation through eval(interpretation of programs), structured text(s expressions) and complex parsing, automatic reference counting, garbage collectors, closures...and so many things that we take for granted today.

If you focus too much on something you become myopic to other things that are also important. And if you don't explore those other areas, you don't even know that they exist.

Programmers run much better with high-level languages. For quantity-1million, yes the efficiency matters. For quantity-1, the structure is very different.

There used to be (maybe still are?) "BASIC Stamp" microcontrollers that run tokenised BASIC. This is the next evolution of that.

(The C environments work, but the manufacturer-provided ones are often a bit ropey!)

Sure. But they're powerful enough that they can run higher-level languages these days, and it lowers the barrier to entry for people wanting to do hardware projects which is pretty cool.

TBH i found for some use cases JS is much better than C for MCU. Simply due the nature of javascript and it's eventloop MCU could automatically sleep without writing any additional code. While on C you have to use some kind of scheduler that switches power mode of MCU by yourself.

A programming language is just an abstraction (built on other abstraction, typically) of turning transistors on and off. JavaScript is most often run in a runtime like v8, but you could build alternate runtimes or event a compiler to target some VM bytecode or an architecture.

One of the things that makes interfacing with hardware (as a software engineer) joyful is having your toolsets match your expectations and mental models of how you want your solution to work. JavaScript was built as a language for interfaces and what is hardware? It’s a physical interface. I personally don’t find it totally unsuited for microcontrollers.

The same thinking applies to PCs and supercomputers, but sometimes we trade efficiency for convenience. That's happening in the "microcontroller" space too (which are surprisingly powerful nowadays).

In short: yes.

BUT maybe it does not matter that much for some projects and a lot of people can write some logic in js a lot faster than in C (or C++ or Rust or..).

Also, there are a lot of people who know only js and would like to "play" with some LED, fetching room temperatures, opening closing doors etc - this is a nice way to start.

There are a lot more info about performance here: https://www.espruino.com/Performance

Technically yes.

But in term of development running JS allows devs to code on their PCs and to run some tests on PCs. So once code is ready on some level to be deployed on microcontroller.