> I did not mean to disparage it just because it was developed for a particular domain.

Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend.

It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing to see it replacing languages like Swift or C++ in computation-heavy systems programming - or domains which should be the preserve of systems programmers.

> However, if "An embedded system uses the internet to communicate" has become synonymous with "It runs linux and uses web services and nodejs" then that would be a perfect example of contorting the application to match the technology that more programmers are most productive with.

I absolutely agree. No quibble with you there! I'm a fan of using the best tool for the job. And, much as it's a meme, I absolutely adore Rust for lots of systems programming applications.

PS: If what you love about Rust is its safety even more than its speed, then I'd recommend looking into Ada, which could be called the precursor of Rust. It has none of Rust's modern trendiness, but it's a mindblowing accomplishment in TypeScript/Haskell-grade type expressivity (with Rust-grade safety) while still retaining I-believe-greater-than-Rust speed.

Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal. It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they could write for, say, Ada or Haskell.)

To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.

Sorry, you're the second person to say this, so clearly I didn't phrase my comment very well. I meant that it's the interpreter which has undergone the most optimisation, or alternatively which has had the most brainpower dedicated to optimising it.

I don't mean that the resulting interpreter is the most performant interpreter in some given benchmark. Like I said in my other reply, I don't think that can possibly be a meaningful benchmark, given different languages have different grammars and semantics which have a huge effect on the possibility of writing a performant interpreter (see: Python).

I can see that you preempt this point in your comment, but, I mean, what on earth does "roughly comparable languages" mean? Comparable how? Even superficially similar languages can have semantic differences which have a deep impact on optimisability. (For instance Python's C ABI, invisible to most end users, which notoriously limits interpreter implementations. Or its bytecode dispatch. Or its attribute dynamism, precluding memoisation of lookups. The possibility of `eval` is an enormous one too, which also applies to JS.)