> The author fails to point out why would anyone want low level memory access.
To get out of the sandbox and wreak havoc? No really, NativeClient is the __last__ thing the Web needs. In the end people will either port their old, bug ridden and insecure C++ code to that thing or they will write new platform dependent code... or both at the same time. That's completely against the OpenWeb.
Worrying about sandbox escapes from NaCl is silly when you consider the insane attack surface that existing browsers expose to the JS engine.
I don't worry about NaCI itself, I worry about someone who's too stupid to implement it correctly. And those people are everywhere, especially in big companies. i.e. Nintendo, broken (self built!) RSA in the Wii or even better Sony, using the same "random" number for all their crypto on the PS3... yes FX and Chrome are Open Source, but MS and Opera are not.
Anyways, I'd rather spent a lot of time improving the JITs instead of writing "optimized" low level code myself these days.
You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though.
Personally, I'm a huge fan of the everything-managed approach (hell, I started a pure-managed OS project for a reason), but I don't think that's a reason to avoid NaCl.