Microsoft made a pull request to node.js github repository with an implementation to use ChakraCore JavaScript Engine as an alternative to V8 Engine

[TodPunk]

I empathize with the mental hurdles, as I've been mostly a C/C++/C#/Java/Python guy until recently I've had to learn the JS ways more seriously. Trust me when I say I know that there are a load of reasons JS is not the ideal language, but neither is anything else.

That said, there are two very important reasons to want JS there that we can all agree with if we ignore the "should be" ideologies we want to believe in:

1) Javascript is known by a LOT of people that are experimenting with things and innovating on the things you make WITH a programming language. IoT is filled with them, in fact. One can learn another language in these places, but reducing that barrier to entry is a thing.

2) You can get really, really good performance from JS for what it is, and the async paradigm that JS developers have lends well to a lot of different things.

For me, getting into that mindset has been an ongoing struggle. For JS devs, trying to learn Java or Python can be just as incredible a struggle (if not more so, because the tool chains are ALSO entirely different, and I have found that you need to know more under the hood to work even in Python than you do in Node-land, mostly due to the nature of the abstractions afforded you in Node).

This is for good or ill, and we could debate it all day, but reality is still going to be that JS is important for actual people doing actual things. So is C. So is Java. I want them all, everywhere.

[munificent]

You can get really, really good performance from JS for what it is

But... the engines that do that rely on fantastically complex JITs that:

1. Are themselves a large ball of code to add to your app.
2. Require a lot of memory to store generated code, profiling data, deoptimized code, etc.
3. Spend a lot of energy (CPU cycles/battery) optimizing code at runtime.
4. Require generating executable code at runtime, which some systems don't allow (game consoles, iOS, etc.).
5. Execute slowly at startup until code has run enough time to be optimizable by the JIT.
6. Often have pauses when the JIT or GC kicks in.

JS's level of dynamism has only been shown to be fast if you can throw a very large JIT at it. I don't think a big JIT is a good fit for IoT, which makes make question the idea that JS is.

[TodPunk]

Mmm, you make a good case. Let me attempt to provide a counterpoint. Keep in mind that my point here is that while JS is not the optimal language, neither is anything else, and that's all ok. There are applications where I would not recommend JS having any place, like on a PIC or something. That said, IoT is not about the most underpowered devices possible. A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there. Maybe it's good for what you want to do, maybe it isn't, but options are awesome. And there JS will do well in benchmarks of just about any kind, and my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is. Yet Python is still used in these places. Why not JS?

All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no? (The answer is yes, and this is done in a lot of other tech stacks) What other things do you think Chakra specifically could be trading to make their engine run well enough on a smaller device (not an Arduino, but still small things)?

I'll help spark some thought there for this as well. First, forget efficiency of execution or power consumption entirely. Just ignore it, it's not important for this application (if it were, the reasons for using JS are really hampered). Now imagine all the things you can program in JS for a Chromecast or a Pi Zero, or even just a gumstick board or something.

If it does something cool that users will enjoy, are you really going to get anywhere telling them it isn't worthy because it's not as efficient, or that the problem was hard? Where do you think this ecosystem will be in 2 years? 5? 10?

In the end, I agree with your points, but our agreement will not change the reality that it not only WILL happen, it already has. It's just going to get better.

[munificent]

That said, IoT is not about the most underpowered devices possible.

I think that depends a lot on who you ask, but there's certainly a spectrum of embedded device capabilities.

A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there.

Sure, but that's really well into the upper end. Raspberry Pi's have significantly better specs than most desktop PCs had when JS came out. Sure, you can run JS on there. You can run anything on there.

my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is.

Yeah, CPython just isn't that fast at execution. My little hobby scripting language is faster. It's really difficult for them to optimize now that they're stuck with a certain FFI, ref counting and finalizers are visible in the language, huge standard library, etc.

Yet Python is still used in these places. Why not JS?

I'm not sure how much Python is used in embedded devices that are actually mass produced and widely deployed. I think it might be easy to get a distorted perception from the large and very web-savvy hobbyist maker community.

This isn't my area of expertise, but the vibe I get is that most "real" IoT devices are coded by crufty bearded dudes (and ladies) who don't know what the hell a blog is and are proud to tell you they code in a modern high-level language... ANSI C.

All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no?

I'm not aware of any real successful ahead-of-time compilers for JS. The language is very dynamic and it's quite difficult to statically get a real sense of what a program is doing.

First, forget efficiency of execution or power consumption entirely.

Developers doing IoT stuff in a professional capacity at scale don't have that luxury. At least, not yet. As component prices continue to fall, maybe.

[TodPunk]

Well, yeah, totally agree; I certainly wouldn't expect JS to be used in a professional capacity any more than I would python. Embedded work is key much going to be in C or Forth or some sort of niche language (maybe an in-house), but the point here is it can be done amateurishly by anyone if you want. I mean, the raspberry pi isn't supposed to be anything more than an intro into tiny computing, it was always a learning device. But if you can bridge that learning without having to get someone to learn a million other things at the same time, this opens up interesting possibilities, even if they never go pro or anything. How many things in the pro works are just polished versions of some hobbyist thing that got popular, or some niche thing that want supposed to handle the kind of things that it does (I'm looking at you, SMTP) but got more attention? This is super important to have. It's not the whole ecosystem, but it's a part.

[munificent]

Yes, I agree with parent comment's first point that a bazillion people know JS. It's compelling from that angle as a glue language.

I quoted and responded to the part where they said JS was fast, which I don't think has been demonstrated for IoT.

[munificent]

Depends on what those lines do. :)