A new "systems" language? Really? What about an IL to replace Javascript as the lingua franca, rather than doing this?
I never understand people who complain that free project X exists, when those people could be working on Y which is obviously more important. As if production and enthusiasm were both zero-sum and fungible.
Also, as someone who works with systems languages every day, I can tell you that there's a need for this work. I'm not saying Rust is it, but the systems language space is pretty dead, which is scary in a world where processors are threatening to become parallel on scales we don't know how to deal with with traditional tools.
But if you ask me "Do you agree?", well do you want my answer, or do you want me to simply say, "If that's where your passion is".
My honest answer, no I don't agree. I don't think we need a systems language of this sort. And I think there's a bigger gap that I'd like to see Mozilla work on, although maybe this blog post author isn't the right person to work on it.
It's unfortunate that the most popular platform in the world will continue to look like it was cobbled together by CS 101 studwents who weren't particularly great students, and were drunk.
People thought Windows 2.0 was bad as a platform. It's like we have Windows 2.0 for the life of the web because there's too many vendors in conflict to actually make it decent.
Both the JVM and the CLR fail to run other than their premier languages, or nearby languages, very well (fast enough or with all features in the "port"). Continuations? Hah. Invokedynamic has taken way too long and the JS VMs have run laps around the JVM.
Yes, browser vendors will also not agree, and for these good reasons among other more "selfish" ones. Get over it.
This would be a long lead item, but one worth doing. I know the Mozilla folks got a kick out of the recent IE9 DCE issue, but I think most people who don't really care about your rivalry, agreed with your assessment, but thought that it continued to show how broken that JS is as an IL.
The point of doing this is to really get a bytecode that will allow language designers to build performant languages that still are first class citizens in browsers.
Unfortunately, the end result, as you say, is that we as developers need to simply get over the fact that we should expect more of our vendors.
It's ironic that people speak of everyone will build webapps with HTML5, yet when Apple and Palm pushed web-centric apps, no one showed up. When they moved to a "desktop"-model, the apps came. Its apparent why. The web doesn't care about devs -- and unsurprisingly the shallowness of most web apps is the result.
That IE9 Dead Code Elimination JS optimization that seemed strangely overtuned for one SunSpider test has nothing to do with JS source vs. bytecode. It does show how poor the industry-standard benchmarketing tests are (Apple is fixing to use the result of the loop, btw).
If you assume DCE happens upstream of transformation to bytecode, you assume more tooling than most web developers I've spoken to prefer to run. And anyway, web developers generally don't write useless yet computationally expensive loops!
But let me agree that it's possible a bytecode for JS could catch on, if only it could be standardized and implemented in all the top browsers.
Then we would have the versioning and future hostility problems I've mentioned, along with some other languages than JS being developed, which might or might not catch on.
So why don't we standardize some (or any, to read your comments) bytecode? I listed reasons including NIH and patents. Those are the "bad" ones but they're real. I don't think they afflict Mozilla, so kindly spare me your inflamed sense of grievance against "vendors".
Regarding web-based apps vs. native apps, see:
http://www.avc.com/a_vc/2010/11/html5-mobile-apps.html
and also
http://www.emarketer.com/Article.aspx?R=1008010
Opinions vary, but web-based apps if not "web apps" are trending up, not down.