Low level memory access, pointers and the likes are the 'horrors' Java/C#/<name your high level language> programmers are running away from. The author fails to point out why would anyone want low level memory access.
> Preemptive response: But NativeClient is x86! Basing the open web on a peculiar, old instruction set is a terrible idea! That’s why I point to LLVM and Portable NativeClient (PNaCl). It’s not a burden to target PNaCl by default, and cross-compile to x86 and ARM if they matter to you.
This seems to imply that the browser should have a compiler that complies the low level bytecode into real machine code. The author should realize that this would be almost identical to running an SWF or a Java plugin, which makes the whole idea pointless.
"The author fails to point out why would anyone want low level memory access."
Please read Tom Forsyth's postings that I linked at the top of mine. Basically, in the last 30 years, clock speeds have gone through the roof, but memory latencies have only increased a couple orders of magnitude. Thus, memory is a primary concern in any application where low-level performance matters, like the ones I listed (games, simulations, video, DSP).
I would have nothing against a site that sends me source code to be compiled within my computer so it could run inside a sandbox, but I won't like when Facebook starts pushing binaries I should trust won't break out of the sandbox they should respect. You can't easily do static analysis on binaries.
And I would love to be able to browse the web on my SPARC, POWER and MIPS boxes.
The binary format in question here is LLVM-BC, which is just a compact representation of LLVM-IR, which is a single-static-assignment representation specifically designed for static analysis. SPARC, POWER and MIPS backends already exist, FWIW.
Well... I wouldn't.
In fact, I can't understand why taking more or less the same shortcut to a dead-end Java took a decade-and-half ago is suddenly a good idea and why disagreeing with it means dooming the web to failure.
That's what I'm getting at here. Executing remotely downloaded code is scary, but we already do that.
And the problem with Java was that it had terrible performance. The idea of NaCL is that it will actually perform better than what we have now.
It had, indeed, terrible performance in 1996.
> The idea of NaCL is that it will actually perform better than what we have now.
The original article here does an excellent job of explaining why. Did you read it? In particular, his reference to Tom Forsyth's article on Moore's Law versus Duck Typing is very informative. And his reference to the game Supreme Commander makes it pretty clear what level of performance he would like to see web-deployable pieces of code achieve.
Those years of experience can be brought to either solution, can't they?
I watched the video that junkbit posted a link to here, and they appear to not trust the llvm-bc. Once the bitcode is translated to a native executable, they run a verifier on the resulting binary, and if the verifier is unable to prove that the only instructions that can execute are those in thi binary, then they have a strict policy of not letting it run. In addition to that, the translator itself runs as a NaCl module so that if a bug is found, it cannot be maliciously used to escalate privileges.
Their approach seems pretty reasonable to me.
I think we are at a point where architectures are so different that even though in theory, controlling memory pattern is potentially more powerful, in practice, it is impossible to do it right except when you can spend insane amount of time on it. The difference between P4 and core duo, for example, is enormous as far as organizing memory accesses. This is exactly like ASM vs C: you can still beat C with ASM, but doing so across all architectures is almost impossible to do it by hand.
Those should not run in a Browser, they should on a real OS (or Emacs).
What's next VMWare inside your Browser? Then it's OS -> Browser -> VM -> OS -> Browser...
Sorry but just because things are possible, doesn't mean that they should be done...
1. Millions of users, who play them happily each day.
2. Sites like Kongregate, Armor Games and Newgrounds, whose business is to publish them.
3. Sites like FlashGameLicense, whose business is to help the business of developing and publishing games that run in browsers.
If something can be done, someone will probably try to make a business out of it. If it catches on, then people who say "just because something is possible, doesn't mean it should be done" are wasting their breath.
Seriously, people managed to write successful, cross-platform software without expecting everyone with any kind of gadget or device to run it with one click.
Why? It was not so long ago that people would have said the same thing about an email client.
I'd disagree. Minified JS source is about as "open" as LLVM bytecode - you won't read both with your eyes. And they are both standardized, have FOSS implementations etc.
> Low level memory access, pointers and the likes are the 'horrors'
It seems that everyone are missing the main point of PNaCl. PNaCl is NOT a tool to give programmers a headache with manual memory management. It IS a tool to give them ability to write in Python, Ruby, Perl, Haskell, Go, C++ and so on - in any language that can be compiled to LLVM bytecode. And mix them to their heart's content.
> This seems to imply that the browser should have a compiler that complies the low level bytecode
There are many obstacles, unsolved problems and distractions (like x86-only NaCl), but the overall direction is right.
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.
Anyways, I'd rather spent a lot of time improving the JITs instead of writing "optimized" low level code myself these days.
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.
I'm sure this attitude will survive for many years to come, although it really shouldn't.
Let web-browsers remain good at what they're good at, and what they were meant for: Browsing the web. Web browsers make great hypermedia navigation / browsing tools... but they're really not so great at being the universal standard remote client interface for complex applications. :-(