Useful response from one of the NaCl team members in regards to the language-agnostic nature of this technology, which is a native code runtime (which means you can compose in a number of languages as long as the
runtime-executable code is native...):
written in C/C++. In fact, you can write NaCl modules in Go, in Python and Lua using ports that contributors have submitted, and you can even write hand-coded assembly in Native Client
if you so desire!
So why don't these compete? Because we think there are parts of web apps people want to build in JS and some parts of web apps people want to build in other languages. Take our video editing example. I'd rather build most of my UI and features in JS – it's
easier and will be just as responsive. But when I want to do the actual editing of the video data, which requires bit operations etc, I'd rather do that in C++: working with binary data is easier in C++, and will certainly be faster. Plus, there's tons of
legacy code out there written for video editing that I can much more easily leverage by porting to NaCl than by rewriting in JS.
Hope that helps explain things.
I've always found this to be an interesting approach, but I do not think they have solved the security threat potential.... Also, one could argue that the IE9 model, run HTML5 close to the metal (surf on metal is my way of describing it) plus blazing JS
execution should eliminate the need, from users' or sufers' perspective, for a NaCl type of solution.
I really like the direction IE 9 is taking in this reagard (take full advantage of the underlying machine, pass the heavy lifting to the OS, etc..). Looking forward to the next Platform Preview...
Surf on Metal,