Lua has a significant strike against it in being 1-based when everything embedded you'd want to put Lua on is 0-based.
In addition, the point of having Javascript is so that I can get my junior software folks (proxy for any inexperienced programmer) to write things for my embedded hardware instead of having to haul out my senior staff engineers who have 20 years of experience writing C for embedded devices.
Look at Arduino vs. Raspberry Pi/BeagleBone. Arduino has way more developers because it was orders of magnitude easier to program. Ecosystem is important.
How does this compare to duktape (http://duktape.org)? I really like duktape's API and documentation (stack-based interface similar to Lua and the doc perfectly describes how each function call affects the stack state).
The API isn't stack-based. It's more like the Python C API, complete with reference counting (but note that actual memory reclamation is done through mark-and-sweep GC), except that instead of everything being a pointer to an object, numbers and booleans are represented directly, so a union is used to represent values.
Because 'scripting' hardware (coding in a fairly high-level language) is a lot of fun and coding the same sorts of things in C is pretty painful & requires up-front knowledge of a lot of stuff you don't really need to know til later (memory management, types etc).
Sure there's Lua et al but JS is just a more relevant language nowadays.
JavaScript is not that high-level anyway, and there are many high-level languages that are much more embedded- and realtime-friendly. Why choosing JavaScript over the much more suitable ones?
Because people know it. That's the only reason, but it's a huge reason.
...though I'm not sure what languages you think are more high-level that are not thereby made somewhat more difficult to use by beginners and/or on small projects, which would rather defeat the purpose, since the actual code running on these cheap microcontrollers is usually relatively small.
> Won't ever be "fastest" in embedded, no way you can run your v8 on such devices.
V8 won't always be required for fast Javascript. If Web Assembly[1] pans out as planned, I can foresee embedded devices that can execute wasm code natively (or at least fast)
Web assembly, as well as asm.js, is never meant to be manually written. It's a target for compilers. And even the most efficient ever implementation of web assembly won't make your plain old javascript any faster.
Examples? I gave a hat-tip to Lua and suggested why JS wins in this case (same argument for langs like Nim). Ruby and Python are too slow (currently). Go and Rust are fast but relatively low-level, tough-going for newbies.
Both Lua and JS are dynamically typed, which is not a very good idea for the low power, limited resources devices. There is a number of relatively high level, statically typed, compilable languages: Ada, Oberon, even the good old Pascal would be ok for the beginners. Not ideal, but at least much better than JS.
In practice with Lua, being dynamically typed isn't really the metric we're concerned about for power consumption. Typically Lua is used as a scripting interface to native APIs and hardware (via C). This is where most of your power consumption is going to live. Powering up a wi-fi antenna? That's going to cost way more than anything you can measure in Lua. Writing a video game? Your GPU is consuming most of the power.
And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space.
And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip.
Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs.
Of course interpreter always eats up more cycles (so, more power) than a native code. Does not affect much peak consumption, but drains battery integrally.
Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such).
And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.
JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. It may not be the best option for any given environment, but that is besides the point. From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in.
That argument is incorrect. According to TIOBE[1], JavaScript ranks as the 9th most popular programming language with a "Ratings" of %2.194. Behind Visual Basic.NET and PHP.
> It may not be the best option for any given environment, but that is besides the point.
No... that is the precise point "sklogic" is making.
> From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
Or, ignoring people with embedded systems experience, put PHP on a chip and hire people who know it.
So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?
From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
MOST software development these days has a web component... not all, but most... that means JavaScript... I would posit that more developers have used JavaScript to some degree than any other language... not their only or primary language.
My argument was to the number of developers who know/use JS... not the language with the most deployed instances. Also, calling out JS for being bad, and suggesting PHP as a language to use is a pretty bad alternative... especially given that everyone who's written PHP has also, most likely written JS.
Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries. I can see the argument for Lua...
> So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?
Many do by way of Java ME[1], though that would not be my first choice. As I said regarding your premise of a business case:
> > From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
The vast, vast, majority of embedded systems are written in one of the aforementioned four languages (with a nod to Java ME since I do not have metrics regarding its production use in embedded systems). There exists a huge software world outside of the browser.
> From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
Reviewing my earlier comment revealed that I forgot to include the referenced link. It has been updated to help disambiguate that post.
From it, there is a definition[2] of the "Ratings" I quoted:
The ratings are calculated by counting hits of
the most popular search engines. The search query
that is used is
+"<language> programming"
The number of hits determines the ratings of a
language.
...
The ratings are calculated with the following formula:
((hits(PL,SE1)/hits(SE1) + ... + hits(PL,SEn)/hits(SEn))/n
where n is the number of search engines used.
By this definition, their "Ratings" are not based on LoC.
> MOST software development these days has a web component... not all, but most... that means JavaScript...
Giving the largest room for expression, I'll interpret "a web component" as software having some form of networking capacity. With that caveat, sure, network communication is very prevalent.
However, assuming this implies JavaScript is a straw man argument[3]. Much network communication exists outside the browser as well.
> Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries.
I disagree with this, but respect your right to have that (and any other) opinion. In an attempt to keep from going completely off topic, I won't go into this anymore in this thread :-).
I was actually referring to a web based user interface...
I did a couple of searches on indeed for phoenix, and san francisco, and JavaScript seems to outnumber C++ and C# by a bit, and be fewer than Java.
For interpreted languages, Python was similar in SF, but less in Phx... and ruby was less in both. And there's also the most popular languages on github (#1 being JS).
Because millions of web developers know it, and if you make IOT type products you'd like to peel off a few of those people to work on your emerging platform.
Who need "developers" of this kind, who are unwilling to learn something as small as a language? And they won't be able to transfer any other knowledge from their realm of web browsers into embedded, besides this thin language layer. So, what's the point, again? I cannot see a single rational reason.
That's a very important point. As an unexperienced developer, you can learn C in a few weeks. Then spend another few weeks on learning how to write clean, maintainable code. I wouldn't want to work with people who don't even want to do that. You already named the most appropriate tools (Assembler, C, C++, and Forth), and learning at least one of them is very easy.
Pick the right tool for the right job. That's what I read all the time. The current approach of 'the industry' is porting JavaScript to just about everything, which is insane. But, you know, learning JavaScript is simple and that's what matters! Well, JavaScript isn't that simple. But writing insane, ugly code and making it run by accident is easier in JavaScript, for example, than in one of the more complex languages.
I've seen things. Things I couldn't imagine in many other (static) languages, because it wouldn't even compile. Things that let me ask 'how did you even get this job?' over and over again.
lowers the barrier to entry to embedded programming.
Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system (and vice-versa, but maybe less so.) IMHO lowering the barrier to entry is just going to result in many more buggy/insecure IoT devices... (JS does eliminate certain classes of bugs associated with traditional embedded languages like C, but there are plenty other bugs you can find in web apps that are not buffer overflows.)
Be careful not to conflate web programming with plain-old JavaScript the language. A lot of the horrible bugs in web programming come from the massive complexity and size related to web browsers, the DOM, and over-engineered frameworks.
If we're talking about streamlined, embeddable JavaScript, we're not bringing the web and all those bloated frameworks.
You are right that those writing web apps won't necessarily be good at embedded systems, especially since (for now), they will have to also separate web APIs from JS-the-language and will not have the APIs they are used to.
But those who survive the transition process will likely pick up better habits. I suspect the APIs and usage will end up looking a lot like the Lua sphere, though perhaps more fragmented since none of JavaScript engines have anything remotely resembling compatible C API interfaces.
> Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system
Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
Depends on the age of the field. When fields are young, nobody has any domain knowledge anyway, because the "domain" just got started. At this point, things like technical knowledge, familiar programming languages, and common data protocols are crucial, because that's all the knowledge that exists.
As a field ages and accumulates best practices and social patterns, domain knowledge becomes relatively more important and technology choices become relatively less important.
Many of the biggest profit opportunities in a field come from owning the platform it's built upon, which is why it's logical to try and attract developers early with technologies they're familiar with. Eventually domain knowledge will matter more - but that depends upon the platform becoming big enough that it's a domain.
Domain knowledge of the type relevant to programmers in many fields is gained through experience programming in that field, not non-programming experience in that field.
Unfamiliar programming language is an impediment, for many, to that learning process. If the tradeoff for that is a much clearer mapping to the domain than a more familiar alternative, the unfamiliar language may be, pedagogically, a net win, but -- especially for self-study -- people are more likely to learn enough to look deeply into the domain (including through unfamiliar languages) if the initial entry path is easy from where they currently are.
The problem in this particular case is that the concerns of embedded systems are orthogonal to what anyone who knows _only_ JavaScript has ever dealt with. Those worlds are simply too far apart.
Your case is entirely valid when, say, a person is hired to work in a retail system and who had previously worked in some form of a decision support system.
It would probably be OK if all programs have a simple, predictable sequence of malloc and free that they call in a loop, with similar-ish sizes each time.
It's extremely unpleasant to program something with just a few KB of RAM and not know exactly what memory goes where. However, a lot of IoT-related gadgets just gather a buffer of data from an ADC or something, average it and send it over some wireless protocol every 1 minute. The allocation pattern is predictable enough that you don't run into strange cornercases.
I see no reason why anyone would want to use this commercially, but for the enthusiast market (and maybe even for some rapid prototyping) this looks interesting enough.
It seems to me that consistent allocation patterns would help more if JerryScript used reference counting for memory management, perhaps with mark-and-sweep GC as a backup to handle cycles. As it stands now, each object has a reference count to keep it alive while it's being used by C code via the API, but actual deallocation is done via mark-and-sweep GC.
had the same thought, why do I have to do everything with JS, sometimes I think it's only to satisfy "Atwoods Law" again and again :) would do it in Go lang, not as raw as C but good and up to date enough for this purpose.
JerryScript needs 64 KB RAM, 200KB ROM. So what can it run on?
Ardunino Uno (ATmega CPU): 2KB RAM, 32KB ROM - Too small.
Arduino DUE (ARM CPU): 96KB RAM, 512KB ROM - Yes.
Raspberry Pi (ARM CPU): 256MB RAM, 1GB+ ROM - Yes, but why?
On the Raspberry Pi, of course, you can run Go programs. Or anything else that runs on Linux. It won't fit on the smaller machines. There's no need to run a Javascript this tiny on the Pi.
So the target for JerryScript is machines in the Due range. Rust has been crammed into the Arduino Due, which may become a good approach for embedded work. Go probably won't fit; too much runtime.
They're all in the $25-$45 price range. The Due, surprisingly, is the most expensive.
The ESP8266 may be a good candidate. tmrmr already said in these comments that some other company had ported another JS engine to the thing. And the world isn't just Arduinos, Raspberry Pis and other nicely-packaged "hacking" solutions.
Yep, I've been running Node.js on a Raspberry Pi with Arch Linux ARM embedded project for a couple months now. It works great, other than the startup time for Node being pretty rough.
IIRC, I believe the Tessel guys are abandoning the transpiler approach in favor of slightly more powerful hardware for the next generation that can just run node directly... We're really at a point where for the types of projects people want to run for under $100 of hardware, it's fast enough to do a lot more.
Power is a bit of a concern, and it all depends on the environment... being able to get every web monkey coding in more environments is a big win for enthusiasts and commercial applications for limited scope projects... Hell, without a screen or antenna powered on all the time, you can get a lot of processing done on even a smart phone from two generations ago.
This has been around for a lot longer than Samsung's (as far as I know) and has a lot of great support. If you're looking for a small, embedded JS processor built specifically for this kind of thing, I'd recommend Espruino.
My first thought was "jerry-rigged". Rather than starting the almost inevitable conversation here ("jerry" vs. "jury"), I'll point out the following SE answer[1]...
It looks very constrained in what it supports so far though.
Update: They're at ECMAScript 5.1 https://github.com/Samsung/jerryscript/issues/205 but not all tests are running https://github.com/Samsung/jerryscript/issues/158
Ok, it doesn't yet JSON.stringify https://github.com/Samsung/jerryscript/issues/432 so not sure if ready yet.