agreed - these guys, like Raspberry Pi, are making a bet on Moore's Law - that's been a good bet for forty years and will keep being a good bet for a long while yet - certainly long enough to make the cost of interpreted JS insignificant
Javascript web code epitomizes the "long tail" of random ideas being articulated. The code is written quickly, needs to change a lot in response to user behavior and designer inspiration. It's usually < 10k lines, so its terrible medium- and long-term maintenance characteristics are manageable. It's written by millions of independent teams to bring to life millions of small ideas used by (typically) only a few users. And that's great, we really need languages for that.
But, humor me for a minute, and let's define "the C law": Anything important enough to be used broadly will eventually be replaced by something written in C(++). Why? Because solution X not written in C is always vulnerable to replacement by solution Y written in C with the equivalent feature set, and the demand is now high enough to provide the time and talent. See: every python module ever used by more than 1M people. See: every programming language implementation (incl javascript and luajit!) ever used by more than 100k people. See every operating system, every database used by more than 1 million. See every web server running top 1000 websites. See (almost) every tech startup that becomes a fortune XXXX company, and rolls through its infrastructure rewriting its ruby or its python or its perl in C/C++/Java. See why we're not all using jitted PyPy yet (hint: those pesky c modules make real world cpython often just as fast or faster and more memory efficient).
Languages that trade performance and correctness for productivity are fantastic when the project is young, small, and of dubious value (yet), or narrowly targeted and not generally interesting. Or the browser gives you no other choice.
Consumer hardware product development just doesn't align with this kind of thinking. It races right past the C law threshold. Physical stuff introduces serious economies of scale, design costs, significant difficulty of change, etc, where shipping a few hundred of something doesn't make a lot of sense (as a business; maybe as a hobby project).
So, if you're going to (aspire to) ship a million of something, investing in the software side to keep costs down, maximize battery life, mitigate risks related to a misapplied language runtime (not designed or heavily tested on embedded), guarantee performance and latency characteristics, etc, makes sense--the compromises that are appropriate for a website because you want to make a little gamble fast don't apply... you're making a pretty big gamble, and it will take awhile to get right anyway, and your capital needs are higher in general, so doing software "right" to save on COGS is just practical.
BTW, "C" here is usually C or C++, but it can very occasionally be Java [see: zookeeper] or some other JVM thing like Scala. Regardless, it basically represents the final state reached by the tool/language/platform/project race. If your project could be replaced by a version that says "like $project, but fast/battery efficient/cheap!", you are not yet at the end game, and the C law could always be invoked (if the demand was sufficient), and your project will probably ultimately lose the lion's share of the market (or open source mindshare, or some other version of "market").
So, maybe this project is betting on our lives transforming into everyone paying more for their hardware, and everyone using a lot more small/local/boutique type stuff created by small hardware teams. This doesn't really jive with the way technology products are currently marketed, hardened, and distributed, so I'm operating on the assumption that change doesn't happen anytime soon.
It could be useful/fun for hobbyists or prototyping, though.
But ultimately there is always a market below that point - people are selling arduinos now for surveillance or monitoring simply because the market is too small for anyone skilled enough in C to bother.
As the price performance of the hardware drops more of these markets will open up - today the "stuff it use C" point is maybe a 100 units or a thousand. tomorrow a million. then 10 million.
Forgive my hardware ignorance but imagine a system on a chip with the cpu and memory and buses of say today's MacBook Air. everything you want, on a thumbnail, just hook up electricity. If I could buy that for 2 cents I would be foolish if I decided to write almost anything in C till I got real time stats from my first 5 million users.
Twitter did not drop Ruby for Java till they were at the billions of messages level. There are an awful lot of markets and price points between 1000 units and a billion units.
(Especially now when we can realistically talk about every human being having a hand held in x years. which blows my mind but for good reasons)
ps - no I do not think Moores law will hold in terms of transistors in a chip for evermore. but we have barely scratched the surface of "everything on a chip".
(Would be interested on the feasibility of literally a PC on a chip ? If we took a literal count of transistors on say a model two years old and then looked at price to fab that many transistors today what would we see?)
edit: rereading it seems to indicate that there is hardware out there were C is the sensible option - I am just trying to say there is a spectrum of / 8 bit assembler / embedded C-like / DSLs / anything a PC might recognise and that climbing that spectrum is inevitable based on hardware price/performance
I agree, and this could be interesting for some of those small volume domains--but their copy in the slide deck is broadly encompassing and far reaching, implying mass-market products like Nest. I'm just taking them at their word and addressing that application.
If your program in javascript takes 14 times as long to run than the equivalent C version and yet still manages to be performant from a user experience perspective, then you'd better be close to an outlet because we're talking about a beefy and energy hungry processor.
There's a sweet spot related to programming effort and power consumption. I don't think Javascript can hit that sweet spot yet for most devices.
I'd argue that the same problem, but to a lesser degree, is present in other non-mobile devices. I'll buy the one that costs $20 more but costs me $20 less per year on my energy bill.
I think we may even see a bit of a reversal in the current trend of programmer productivity over program efficiency. Clusters of cheap multi-core servers consume significant energy.
There are going to be physical limits to battery technology, to processing power, all of these things. but those limits are not upon us yet and I have a suspicion the true physical limits lie in a place that will make us 20th century simpletons look like slack jawed savages.
I'm betting on science, bitches !
Now, we do know one limit - the human brain fits in an X sized area, and requires Y sized plumbing and energy store to accomplish what it does. My feature requests exceeds what any one brain can do. I'd be astonished if we could shrink that to phone sized, but maybe, just maybe.
At that time we can renew this conversation. Until then, burning batteries, and running data centers, matters. Until then, C (or a safer version thereof) matters.
Doesn't or didn't used to?
> So, maybe this project is betting on our lives transforming into everyone paying more for their hardware, and everyone using a lot more small/local/boutique type stuff created by small hardware teams. This doesn't really jive with the way technology products are currently marketed, hardened, and distributed, so I'm operating on the assumption that change doesn't happen anytime soon.
So, didn't and won't. At least not mass-market. Maybe very specialized, low unit volume kind of applications.
The last time a mainstream OS was developed from scratch was the late 80's (1989 to 1993), with windows NT. Linux is just a kernel for an OS from the early 80's (gnu). OS X is a derivative of nextstep, also developed in the second half of the 80's. C was the state of the art back then.
The investment to build a competitive mainstream OS from scratch in a new language is huge. Probably 10x to 100x the effort to build windows nt, which took 250 people 5 years. I think there would be a lot of value in developing an OS in a programming language that deals intrinsically with the topics of security and multi-processing, but at this point it's too expensive to do that and match other OS's feature for feature.
EDIT: for an example, compare linux/drivers/ to linux/kernel/ (core kernel code, including process management and scheduling) and linux/mm/ (memory management) in Linux. The former is huge.