[haberman]

> NaCl? Not portable.

To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test...

> Defined by implementation.

As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be standardized at this point either.

> No view source.

It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable. I'm guessing it will be about as readable as the portable BitCode that comprises the PNaCl image (which you could view if you really want to).

It's disappointing to continuously see this anti-NaCl propaganda from Mozilla. Here you have a promising and highly innovative technology that is pushing the bounds of what is possible on the web. It's being developed completely in the open with papers and code being published continuously. Mozilla's mission is "to promote openness, innovation and opportunity on the web." I just can't see what part of that mission involves campaigning against an open technology that could advance the web and help it compete with native apps.

I could understand if their position was "we're reserving judgment until it's portable, stable, and standardized." I could understand "we want to be more involved in the process." I could understand "we are waiting to see if it can demonstrate a compelling advantage over JavaScript." But everything I have heard indicates that they are publicly and completely opposed to ever supporting it, which will make it all the harder for them to ever change their mind on this point without losing face.

I grew up watching Mozilla develop from an unstable binary called "apprunner" into a full-featured open-source browser with cutting edge extension capabilities. I downloaded almost every single milestone and tried it out, craving the day when I could ditch crappy old Netscape 4 for good. I got warm fuzzies when the Mozilla Foundation was created; it felt good knowing that there would always be a way to use the web with open source software, and that there would always be an advocate for openness and freedom. I just never expected to see them fighting against open technology. It's disappointing.

[BrendanEich]

PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format.

PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified nowhere and implemented only in chromium.org code.

To say this is "Open Technology" is to reduce "Open" to the level of "Big company Big Bucks Open-washing." There is nothing open about an unspecified research project without a proven multi-party governance structure that's dominated from start to finish by Google, and which only Google could afford to staff and push -- including via big-money distribution deals with game developers and distributors.

As I said at Strange Loop and in past talks, don't shoot the messenger: Microsoft and Apple will never adopt NaCl/Pepper. It is a non-starter as a web standard.

Why pray tell should Mozilla fall on Google's sword here? Why should we beg to be involved more "in the process" years after it started? Who are you to say that NaCl/Pepper is better for developers or anyone else than a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

NaCl/Pepper looks like an incumbent power's technological folly, similar to Microsoft Active X or Google's Dart-as-a-native-VM. Just because a big company can pay for it does not make it "Open" or "Good" or good for the web.

You've been free with charges of dishonesty, but I'll refrain from drawing conclusions about you from your position except to say that what you write is astoundingly naive -- at best. For anyone building a competitive browser that is not Chrome or chromium-based, what you propose is a money pit in direct and opportunity costs, with no clear path to standardization, where Firefox would always be behind in "Pepper conformance" compared to Chrome. The answer is no.

You'll get the same answer from any other browser vendor not free-riding off of chromium/Google.

[haberman]

There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to jump on what is perceived as a "Google treadmill." None of my comment was about any of that.

What I can't understand is the fundamentalist reaction to the very idea of native code, the ignoring/dismissing of serious work to solve the problem of portability, the liberal use of words like "never" and "non-starter," spread of FUD by invoking inaccurate comparisons like ActiveX (vis a vis its security model) and DLL Hell, and the spreading of misinformation. For example, PNaCl is not, and as far as I can tell never has been, dependent on machine word size. The link you cited doesn't apply because it is arguing against a different approach than what PNaCl actually does.

PNaCl works by defining a little-endian ILP32 machine as the target and fixing all important characteristics of this machine independently of the characteristics of the underlying CPU. This abstract machine's characteristics are defined in such a way that they can efficiently be translated to native code on any modern CPU. This is all covered in the introductory doc: http://src.chromium.org/viewvc/native_client/data/site/pnacl...

> a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

This is a far more reasonable and compelling story. By all means talk up your stuff and argue that you can win in the free market of ideas. I'm not arguing that I or anybody else should be able to dictate to developers what technology they use; on the contrary it is the Mozilla argument of "no one gets to the machine except through our VM and our GC" that paternalistically ties developers' hands and limits their options.

[BrendanEich]

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel.

Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I should have checked to see if it remained one.

This correction doesn't alter the general unreadiness of PNaCl for the web, on several fronts. Pepper is one, but PNaCl performance lagging NaCl is another. The Chrome Web Store features games ported via NaCl, for performance -- not PNaCl, which would be significantly slower. On this basis alone, it's premature for you to push PNaCl ahead of Google.

> This is a far more reasonable and compelling story.

Well, gee, thanks a ton! :-|

I've been telling this story clearly since Fluent in May. That you chose not to hear it and instead flung accusations and told sob-stories about big bad Mozilla is your doing, not mine.

Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)" -- outside of a few dying plugins, which are even source-licensed and co-released.

And that brings back my final point: NaCl is for safer plugins, which are OS-specific anyway. The likeliest evolution of SFI or CFI enforcing compilers and runtimes as plugin hosts is via the OS, not the browser. Write a letter to Microsoft and Apple, not to Mozilla!

[haberman]

If I sound argumentative and fired up, it's because I feel like Mozilla has been casting stones on this issue for years. Imagine how you would feel if Google executives were publicly criticizing Mozilla efforts like Persona, arguing that they would never support them and no one else will either, basing their criticisms on issues that you are actively fixing.

(For what it's worth, Persona looks promising to me personally, and I also like Rust very much, a lot more than Go. I say this to demonstrate that I'm not just a Google partisan and that I admire a lot of what comes from Mozilla).

I am much happier to discuss this dispassionately on a technical basis. I'm much happier if I don't have to argue against what to me are very unfair accusations, like being as proprietary as Silverlight.

> Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)"

I don't understand the argument you are making, (P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC. And (P)NaCl executables are OS-independent. I don't understand what you're getting at here.

[dmorgan]

>(P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC

And this is the argument he's making: that does not fly by browser vendors. They DON'T want to have code run OUTSIDE their VM/GC.

[BrendanEich]

Thanks for the support, but that's not what I meant. NaCl + Pepper is like a VM where the compiler does the heavy lifting so the native code can run safely (Software Fault Isolation, SFI -- wild pointers lead to a safe non-exploitable crash), rather than a JITting or MMU- or hypervisor-based VM doing the heavy lifting at runtime.

It's quite clever, but still enough of a new thing that Chrome also sandboxes NaCl'ed code out of process. Belt and braces are good. No silver bullets.

But a VM is as a VM does. This is part of Google's VM-set and not any other browsers. The rule still applies.

Truly unsafe native code in plugins (e.g., un-NaCl'ed Flash) runs out of process too, and sandboxed to some extent, but it can cause problems that are not contained (and did at the last CanSecWest Pwn2Own contest, IIRC).

[haberman]

He said "including Chrome." Chrome supports NaCl. This does not compute.

[aplzrtve]

These are shallow arguments: * pepper is "inspired" by nsapi, clarify your point. * PNaCl performance lagging isn't a solid argument, you know it'll get better, the solution might even be to cut LLVM out save for bitcode. * "nobody does this at the moment" so why does it belong in the OS?

[BrendanEich]

In reverse order:

* Why in the OS? I didn't say "belong", just "likelier". That is because plugins are native code compiled by OS-dependent toolchains, and OS vendors are few (three that matter) and lock up native code these days via SDK licenses, app store rules, and even kernel-level restrictions.

In contrast, there are four or five competitive browsers, only one of which has Pepper and the rest do not -- and will not.

* I do not know how much better PNaCl can get. The shallow argument here is your assertion that "you know it'll get better". The same could be speculated about JS performance at Emscripten-generated code, and that works cross-browser. That's the cross-browser path of least resistance, compared to the practically unpassable Pepper barrier.

* Pepper is "inspired" by lots of APIs, but here the shallow shoe fits your new-HN-user drive-by. NPAPI is a sunk cost all browsers save modern IE have paid out for years. Pepper is new and much bigger. Have you even read all the interfaces?

The bottom line is that whatever PNaCl performance wins may lie in the future -- and I will believe them when Google does as shown by Chrome Web Store games being PNaCl'ed not NaCl'ed -- Pepper is the blocker for any cross-browser adoption in reality.

This ignores principled objections to more native code on the web, as a "social ill". Let's take that up separately, because it could override any technical argument. I'm happy to stop on the Pepper point for now, since Google manifestly is stuck there.

[aplzrtve]

Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser?

Why wouldn't other browsers have Pepper?

Compilers are as good as what they've been tuned for. In my view PNaCl's shortcoming is startup time because it lacks a JIT and LLVM's back end is too slow for now. Speed up the backend or JIT code and you'll get close to GCC performance while being portable and somewhat language agnostic.

Yes I have seen pepper, and most of the interface relates to the GPU. How is sunk cost better, when a big part of the API can be backed by what canvas relies on?

You would consider adopting PNaCl and pepper in FF if there were games that targeted them? If the code were contributed to Mozilla?

What do you mean by "more native code"? Can't view source?

I appreciate the answers.

[cliffbean]

The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.

[BrendanEich]

Thanks! I happen to agree with with Dan Gohman (http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43...), but I'm not sure where Chris Lattner ended up on this.

Much is possible in software, so perhaps some day, or under some transformation, LLVM bitcode would be suitable as a stable long-term object file format.

There's still a point here: PNaCl is pushing a stone up a very tall hill. ANDF and other Universal Object formats go back to the 70s if not earlier. It's very difficult to standardize such things, never mind Pepper.

[gsnedders]

FWIW, the aim for LLVM is to avoid breaking the bitcode format now 3.0 has shipped — not that it's platform independent or anything else yet.

[hermanhermitage]

Work with say Khronos group to establish an OpenCPU standard with a source code and possibly intermediate representation.

Socialize amongst CPU vendors, and interest platform makers in the mobile and desktop space.

Watch it absorbed by web standards.

[petegrif]

I don't understand why you feel it necessary to make your points in such an inflammatory manner. Your arguments are well made, why do you feel the need to, for example, call someone 'astoundingly naive?' Being rude doesn't make your points more convincing and I would have hoped you were above that kind of thing. It's a pity because you have a huge amount to contribute.

[BrendanEich]

I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not.

Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it, in contrast to my fine counterpart. Yeesh!

[haberman]

Oh come on. My label of "dishonest" was in regards to a statement, not you personally, just like your label of "astoundingly naive" against me.

And I didn't speculate about motives. I'm not sure what statements of mine you're taking so much offense to, but your speech has also been brusque and uncharitable at times ("Who are you to say...", "Here's a final clue:").

I also went out of my way to empathize with Mozilla's concerns and reasoning for not wanting to support NaCl, whereas you show no appreciation for why someone might ever legitimately want to run native code on the web.

[BrendanEich]

You wrote, very first comment at top:

"To dis NaCl on this basis and not even mention PNaCl is dishonest."

That was in response to my slides. You were calling me dishonest. Come on yourself!

You then went on about "propaganda" and scary salt crystals. Something is off right there. Mozilla doesn't make propaganda and we have a tiny fraction of Google's budget (which I can assure you has been deployed commercially to push NaCl).

I don't think your tone or content are balanced on any of this, and you at least climbed down on the salt crystals. Can you do likewise on the "dishonest"?

[haberman]

You seem a lot more interested in getting me to take back things than you are in taking back your misleading slide.

Substitute whatever adjectives you want if the ones I used offend you, but the point still remains that the most vocal criticism of (P)NaCl comes from Mozilla and it is anything but "balanced."

I would feel more inclined to issue an actual retraction if there was any indication that I was mistaken about this or that it would change.

That said I'm not really interested in arguing further, since we've clearly reached an impasse. I admire the work you have done with JavaScript, and I admire the work Mozilla has done over the years on many great products.

[qwinter]

Please stop signing your posts.

[sayrer]

does PNaCl work? do you know the answer to that question?

[haberman]

I have not personally used it, but the documentation at http://www.chromium.org/nativeclient/pnacl/building-and-test... indicates that it is at least capable of running spec2k. I don't know what's complete and what is incomplete. I do know that it is the stated goal of the NaCl project to achieve portability through PNaCl; that alone makes it deserving of mention in this context (https://developers.google.com/native-client/overview#distrib...).

[bzbarsky]

Taking your points one at a time:

1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited.

2) Google is opposed to anyone else being more involved in the process. Other people have tried.

3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the web than we are about our egos or "face".

4) Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Granted, the source is open, but again it's tied to various Chrome-specific stuff that is underspecified and would be incredibly difficult to integrate into any other browser.

Basically, as far as I can tell your argument comes down to saying that Mozilla should be open to implement PNaCl (not NaCl), if it were being developed completely differently and had different goals. We might be, if that counterfactual held. But it sure doesn't, and I don't see any hope of it holding. If that ever _does_ happen, we can revisit this discussion, of course.

[haberman]

> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth.

Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing.

> If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited.

This claim is directly at odds with the public statements of Mozilla's Chris Blizzard, who argues against the very idea of native code delivery to browsers. His arguments aren't against the NaCl implementation, process, etc, they are fundamental arguments against native code in general: http://www.theregister.co.uk/2011/09/12/google_native_client...

> Basically, as far as I can tell your argument comes down to saying that Mozilla should be open to implement PNaCl (not NaCl)

I'm not even hoping for that at the moment, at this stage I'm only hoping for them to stop maligning it publicly, like Chris Blizzard saying it will lead to DLL hell, or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night.

[bzbarsky]

> and released by a company with a history of > "embrace, extend, extinguish."

It's worth considering technology on its merits, not just based on past behavior of companies. In recent years, Microsoft has been much more of a team player in the web space than Google has, for what it's worth.

That said, I didn't claim NaCL was in all respects identical to Silverlight. I said it was comparable. It's more open in some ways (open source), less in others (e.g. no independent reimplementations, and precious little chance of any as things stand). The provenance is equally unpalatable, from my point of view; Google may not be aiming for "extinguish", not least because that's not very likely with the web at this point, but it's certainly aiming for "embrace, extend, coopt", which is not much better.

> That someone who appears to be speaking for Mozilla

In general, people who work on Mozilla speak for themselves. The cases when they're speaking for "Mozilla" are very rare and always marked as such. In this instance, I'm speaking for myself.

> This claim is directly at odds with the public statements > of Mozilla's Chris Blizzard

Chris and I don't always agree on everything. But some of his arguments are certainly valid. I didn't say I'd adopt PNaCl with open arms; just that the discussion should be revisited. As long as we're talking about things that are hardware-dependent, there's just no point having the discussion at all.

> at this stage I'm only hoping for them to stop maligning > it publicly

What you view as "maligning" someone else may view as an attempt to keep Google from pushing hardware-dependent code as part of the web platform, which is what they're trying to do. All a matter of perspective, I suppose.

[BrendanEich]

Was the salt crystal image scary? Boo hoo!

It was from Dave Herman, and it was not intended to be scary at all. It's appealing to physics and chemistry nerds. Salt has had a bad rap, to borrow from Montgomery Burns on eggs.

This is descending into silly-season political talk. Google chose the NaCl + Pepper pun. They can take the scary images, if those images truly are scary.

BTW, Chris Blizzard works for Facebook now.

Back to more serious topics...

UPDATE: to be fair to blizzard, he was objecting (as bz reminds me) on behalf of Mozilla to paving the web with x86 or other machine-dependent code, however compiled. Mozilla still opposes more such machine-specific plugin code. Think of NaCl as a safer plugin compiler, nothing more. We believe the Web should not need plugins to fill decade-long gaps from the '90s that real "coopetition" among browsers in standards bodies can fill much sooner, without the problems that plugins bring.

[chrisblizzard]

So this is why my ears felt warm this morning.

Yeah, even though I don't work at Mozilla anymore, I still think {P}NaCl is a bad idea for the web as a whole (and its users, by effect) and also for Mozilla (as one of its most important stewards.)

Carry on.

[dherman]

> or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night.

Really now. I created that slide, taking the picture from Google's own NaCl web site:

https://developers.google.com/native-client/

I zoomed it in because I thought it looked pretty. Let's all just take a deep breath.

Dave

[haberman]

Mea culpa on that point (the image). I drew the wrong conclusions about its intent.

[laughinghan]

As it should be, until the implementation settles and it's clear what interfaces should be standardized.

I believe Brendan Eich is suggesting that the preferred process is for a technology to be defined by a draft of a spec, and have multiple implementations' interfaces settle down before being standardized, rather than having one definitive implementation that unilaterally determines what is settled down and what isn't.

That seems quite reasonable to me, when such a thing is possible doesn't it sound like it would lead to a better spec for a better technology?

It's disappointing to continuously see this anti-NaCl propaganda from Mozilla.

Could you elaborate on all the anti-NaCl propaganda you're continuously seeing? Is it actually Mozilla's propaganda, or Brendan Eich's personal opinion? Personally, I thought that at least in these slides, he was quite balanced in presenting both the pros and the cons of a technology directly aimed at taking the spotlight from his baby (by being used instead of JS for high-performance browser games and stuff).

[lmm]

>I believe Brendan Eich is suggesting that the preferred process is for a technology to be defined by a draft of a spec, and have multiple implementations' interfaces settle down before being standardized, rather than having one definitive implementation that unilaterally determines what is settled down and what isn't.

As in, Mozilla would implement a common core of NaCL features, perhaps omitting some of the less-core ones that Chrome has, and adding their own extensions, and they could see what was good and what was bad, and experimental features could gradually become part of the standard? Sure, sounds good.

But for google to try and define a standard when they only have the only one immature implementation would just be stupid.

[phaedrus]

I've seen it too from multiple people, and I don't think it's hyperbole to call it propaganda. We had a representative from the Mozilla foundation speaking at our local Js conference and I asked him if the situation with NaCl w.r.t. Firefox was because no one has implemented it or because Mozilla is "morally" against it. He answered that Mozilla is categorically against the idea of NaCl.

[bzbarsky]

Mozilla is categorically against the idea of NaCl, yes. Because it's tied to particular hardware.

PNaCl, if it ever happens, will be a separate discussion.

[mercurial]

The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross-browser bytecode alternative to Javascript, preferably running in a VM accessible outside of a web browser.

[cliffbean]

A lot of people say they want a bytecode for the web. The problem is, bytecode vs text is just an encoding issue, and it's practically insignificant. It's a platform either way, and the real issues are what services the platform will provide.

For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download, and it may mean that the GC can't do all the low-level things that modern GCs do to get good performance. Is this an acceptable tradeoff for the web? I believe questions like this one are the important ones.

[MatthewPhillips]

People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.

[pcwalton]

I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#.

Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all semantics of all programming languages, and I don't believe such a VM can exist anyway.

[btilly]

Bytecode really is nothing more than just a compressed source encoding of some language.

I was with you until you said "compressed".

There are plenty of examples where the bytecode representation is bigger than the original source files.

[MatthewPhillips]

Not sure about the JVM, but .NET compiles to an intermediate language called CIL before creating the bytecode. I agree with you, but to bytecode advocates, this is an emotional issue. They do not want JavaScript to be the first-class language and their pet language to be "held back" by it.

[mercurial]

What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )

[cygx]

That's similar to saying that x86 asm is able to deal with a large number of paradigms. LLVM IR might be a a viable target to avoid writing your own native code generators, but that does not a universal bytecode VM for dynamic languages make.

It sure would have been nice if Parrot had succeeded there...

[tikhonj]

Languages targeting bytcode platforms are just as liable to be second-class citizens as ones targeting JavaScript.

Scala and Clojure don't support proper tail calls. Why? Because the JVM is the Java Virtual Machine! I believe there were similar issue for dynamic languages on the JVM for the longest time as well.

And now just imagine implementing a Haskell->JVM compiler. I wouldn't be surprised if that's actually more difficult than implementing a Haskell->JavaScript compiler.

So yes: with JavaScript as the target, other languages are second-class citizens. But with some bytecode, that won't probably won't change much. Knowing how these things get designed, the end result could easily be that every language including JavaScript becomes a second-class citizen.

[bgarbiak]

It's rather easy to make minimized JavaScript readable again though. For example, Chrome's Web Developer Tools have such feature built-in.

[esrauch]

Readable is a bit of a stretch when the js is thousands of lines of files concatenation together with variable renaming. Google Closure compiler also does function inlining among other optimizations; it's not like you can do view source in Gmail and expect to get anywhere without a lot of reverse engineering effort.

[pcwalton]

Rust is never going to be part of the Web. Content will never be able to execute Rust code. If Mozilla had been proposing to integrate Rust as a potential client-side scripting language (which wouldn't happen to begin with), the process would have been totally different.

[z3phyr]

Thats a good thing. Rust is THE alternative to C++, and it should not lose focus by compiling to javascript.... Rust should not compile to javascript.. It should remain native(LLVM).

@pcwalton Please assure me that rust won't compile to javascript, and it will remain Native (C/C++ compatible, ahead-of-time). Rust is my last haven, let it remain rust only!!

[pcwalton]

Well, we aren't going to stop, or even discourage, people from writing Rust-to-JS compilers, but we won't be working on such a thing...

[z3phyr]

Hey, thanks...

I believe - Anything can reach very high, granted it dosen't lose aim/target... Javascript as a target is intrestingly beautiful, but this might fork up a way for yet another dart. Rust should remain, what its meant for....

[gsnedders]

LLVM doesn't mean native: LLVM means whatever there is a LLVM backend written for, and this includes higher-level things such as JS.

[daeken]

On a side note, has there been any experimentation with Rust on NaCl or with Emscripten? I'd love to write some web demos with it.

[z0w0]

Rust can't run without it's runtime yet, which means the runtime needs to be wrapped into JavaScript code on the Emscripten side. The runtime needs some important parallel and memory functionality and last I heard most of it isn't easily to implement in JavaScript (workers and typed arrays and other HTML5 goodies probably bring it closer to being feasible).

NaCL is a more realistic target - in theory it should be as simple as making the compiler use NaCL's GCC instead of the system's C compiler. However, I don't know about how strict the sandboxing is, there might be certain things that the generated Rust code isn't allowed to do.

[hermanhermitage]

See Xax for another approach.

The issue here is that NaCl and Xax are proprietary approaches done inside companies coupled very tightly with existing ISAs and not developed entirely in the open.

They are both brittle with their own particular weaknesses - NaCl is weak at handling dynamically generated code, and Xax has safety issues (there are user mode instruction sequences that can freeze some x86).

PCC may be clever, but the fact remains less effort would be required to add sandboxing of processes and peons and yield higher performance.

PNaCl from what I recall relies on LLVM which is yet to demonstrate low latency code generation performance - in contrast to older more mature code generators such as TAOS, LuaJit.

Don't get me wrong, I am in favour of a WebCPU component for low latency, near native code emission and execution. I just don't think those with the pedigree are doing the work.

[haberman]

> The issue here is that NaCl and Xax are proprietary approaches

If you had told me in the 90s when Microsoft was king that someday "proprietary" would be used to describe a completely open-source, documented, published technology that its creator encourages others to adopt, I would have laughed and said it's impossible.

> NaCl is weak at handling dynamically generated code

They got it working for x86 (http://static.googleusercontent.com/external_content/untrust...) and it's currently just not prioritized for PNaCl AFAIK.

> PNaCl from what I recall relies on LLVM which is yet to demonstrate low latency code generation performance

Sounds like the kind of problem that can be addressed once other much bigger problems are solved. It's not like any such problem would be fundamental or insurmountable.

> in contrast to older more mature code generators such as TAOS, LuaJit.

I don't know about TAOS but LuaJIT 2.0 (with it's completely rewritten code generator) is only 5 years old compared to LLVM's 12 years. Even LuaJIT 1 is only 7-8 years old.

[bzbarsky]

"proprietary" is a spectrum, not a binary decision.

You can be open-source, documented (though NaCl is not so documented in practice because of the Pepper dependencies), published, and encouraged to adopt, but if your development is controlled completely by a single company and if you depend on other, undocumented, parts of that company's software stack, then you are more proprietary than something with an open (as in, developed in the open, with many participants) standard and no dependencies on a particular implementation.

Obviously you'd be less proprietary than, say, ActiveX, but that's a pretty low bar nowadays. NaCl is not competing against ActiveX; it's competing against the web platform as it exists. And that's definitely much less proprietary than NaCl.

[cmccabe]

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN.

Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope.

We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and Microsoft. pNaCl, same story. Google might end up using it as an app delivery mechanism in ChromeOS; that's about the limit of its potential usefulness.

It's particularly ironic to hear Brendan Eich complain about the lack of a standards-first approach in NaCl, since ECMAScript was designed behind closed doors at a single company. Anyway, ECMAScript seems to be good enough for building web UIs, and it's even a little less verbose than its "older brother" (whom it resembles not at all). So I think its quasi-monopoly is secure. I hope they pull the TypeScript extensions into the core language in the next version.

[BrendanEich]

Rust has a healthy number of committers who are not employed by Mozilla. I will let pcwalton fill in details if necessary.

"Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers.

NaCl is not adopted because it's machine-dependent!

PNaCl is not ready. Show me Chrome Web Store games compiled with it and not NaCl, then we'll talk.

As I've written before on HN (see https://news.ycombinator.com/item?id=2998374, "I've paid my dues"), JS was created by me in a tearing hurry in 1995 for Netscape, the would-be market power that nevertheless avoided a monopoly conviction (unlike the other guys).

There is no "quasi-monopoly" here. Someone on HN schooled me on "monopoly" (http://news.ycombinator.com/item?id=2998590).

The issue with JS is not "monopoly" in the econ 101 sense. The issue is that JS is more than good enough, and getting better under competition and cooperation in the standards bodies. Therefore it is very hard to displace, and just as hard (if not moreso: a displacing language might be backward compatible) to supplement with a second language/VM in all browsers.

You should respond to this technical fact (by which I mean, the circumstance is well-founded in software costs).

[cmccabe]

According to the Apache project, a project is "considered to have a diverse community when it is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)." Rust might meet that standard in the future, but it is not there yet.

With regard to JavaScript versus NaCl / PNaCl / etc-- I've heard all the debates before, and they are kind of tedious. ECMAScript is a good language for some things, but making it the only option is goofy. I think Mozilla is shooting itself in the foot by not supporting PNaCl, which is the one thing that could potentially save their "boot to Gecko" initiative from disaster. I guess the Adobe Flash and ActiveX experience left emotional scars that haven't healed yet. Oh well. Their loss, Apple/Google/Other app stores' profit.

[bzbarsky]

I think you missed my point.

Say you have an open-source project with a single owner, who makes all the decisions about it, and is willing to totally change it around to suit his needs.

Would you stake your business on use of that open-source project? Only to the extent that you're sure your needs align with the project owner's. Unless, of course, you're planning to fork anyway.

That's where NaCl is at the moment.

It's also where Rust is, even more than NaCl. Anyone who is not in the business of working on Servo is nuts if they're relying on Rust for anything important, so far. In my opinion. So yes, from my point of view Rust is definitely proprietary to Mozilla at the moment, and asking anyone else to use it (again for anything important, not just experiments) is just a recipe for disaster.

As far as NaCl adoption, Apple and Microsoft have their own reasons for not adopting it, for sure. But this subthread is about Mozilla's reasons, which certainly don't match those of Apple and Microsoft.

[cmccabe]

Let's check wikipedia.

"Proprietary software or closed source software is computer software licensed under exclusive legal right of the copyright holder.[1] The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering"

Muddying the waters by referring to open source software as proprietary software does not help. And I am sure the folks at Mozilla, being open source advocates themselves, would tell you the same thing.

Reminds me of an ex-boss (from a long time ago) who referred to all open source software as "freeware." Hey guys, the 1990s called, they want their bad hacker movies and confusion about the software business back.

[BrendanEich]

On TypeScript, are you seriously asking for warning-annotations? The class syntax is in for ES6, not original to TS. Or do you mean 'interface' as structural type (record width subtyping relation) declaration form?

[cmccabe]

I like the structural subtyping. This is a feature I also like in Go.

[laktek]

> It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable.

With SourceMaps it's possible to make them readable[1].

Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE.

[1] - https://wiki.mozilla.org/DevTools/Features/SourceMap

[ANTSANTS]

There's audio processing stuff that I'd love to do in web browsers, but I refuse to touch Javascript with a ten-foot pole. I am the kind of person that would like NaCl to be adopted outside of Chrome. If you are the kind of person that is more interested in building the "app" part of some application of that kind of program, you have nothing to fear from NaCl -- just think of it as opening up the "standard native code" (native browser code, like video codecs, gzip decompression, etc) part of the web browser to everyone. You don't really care about what's going on under the hood when your users decompress some data you served to them, as long as everything works properly, right? That's pretty much the definition of something that most web developers couldn't care less about, and that people who do (for lack of a better term) "fast computing" care desperately about.

To give a recent example, what if you'd like to start serving Opus audio to all your users? The standard response to that idea now is "that's funny, Internet Explorer will never even support Vorbis, and that's over a decade old." If safe native code execution was a standard part of the browser right now, it would be trivial to distribute an Opus decoder alongside the "web app" you implemented in Javascript. Opus would just be your competitive advantage, not something you need to beg people to implement. It would already be ubiquitous.

Before anyone mentions X implementation of Y audio codec in Javascript in an attempt to discredit the value of native code execution, just stop. I highly doubt it will work acceptably on my mom's computer (the average computer that accesses your site is almost surely a hell of a lot less powerful than you may assume it is), and I highly doubt you'll ever be able to rival the performance of native code for processing on the order of video codecs anyways. Not to mention the fact that the majority of the nontrivial Javascript audio demos you've heard were made possible in no small part due to standardized, native code linear filtering and convolution.

"Frustration" would be the word that sums up the whole "web app" movement to me. When I see that someone's made a client-side GIF animating "web app," all I can think about is how it would have taken two seconds to hook an existing highly performant C GIF encoder up to some Javascript, and instead we had to wait for someone who knows Javascript to hack a painfully slow (and therefore useless for the vast majority of users) alternative together. You know how ubiquitous similar server-side services are? That's because all it takes to make one is a simple Javascript/HTML form (or HTTP, if you want to get trivial)-based interface to an existing C program. Just think of where client side web apps could be right now if the same were true for them.

[chipsy]

I've been doing audio processing in Flash for a while (most recently, sample-based synthesis implementing a decent portion of SFZ and SF2, with 64-voice polyphony and filters) and I did have to push an unusual degree of effort into optimizing the sample copying code, with a Haxe macro that generates an optimal inlined loop for each combination of parameters. It can still use up most of a core when maxed out...

...however, I did some math and some extrapolation and determined that within the next three to five years this domain will be completely reasonable to approach from JS, driven by a combination of technologies:

-access to GPGPU from the browser. DSP work can generally be defined in terms of a shader, although it's still a very poorly understood area.

-more general-purpose cores, faster JIT performance, and possibly single-threaded hardware improvements as well. These things compound easily, so we could end up with a 50-100x larger JS performance envelope for this domain without even considering the GPU.

-maturation of the existing and planned audio APIs for common tasks. As you point out, this isn't interesting from a "ground-breaking tech" perspective, but in covering typical application needs, it's as important as the others since it's both convenient and optimized out of the box.

-maturation of cross-compilation technologies, smoothing over the "code has already been written" issue.

In a lot of ways, all JS has to do to be competitive is the "catch-up" work. It takes quite a while in tech time, but in human time, most of us will be around in the next decade.

[_urga]

You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX.

What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that.

For example, instead of coding up IndexedDB and leaving no alternative, just provide proper POSIX, and let the database community do its thing.

[gsnedders]

Because there's more interest in improving the (publicly accessible) web as a platform than improving installed web apps.

Regardless, to expose such a low-level API would eliminate one of the big advantages of the web: given a browser, I can use any web app on any device. Given, for example, given a TV (which are typically closed platforms, but increasingly often include a fully featured browser), you likely wouldn't be able to install anything that a certain web app depended on (and even if you could, what are the odds that it's been tested on a big-endian platform?).

[_urga]

No, it would not eliminate the big advantage of the web as you say, merely deepen it.

See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

[gsnedders]

None of what timbl said in that post (nor what anything, from memory, in that thread said) covered shipping native code to the browser: it was merely talking about privileged web apps, which is a very different problem area (and one that should definitely be explored!).

[MatthewPhillips]

How would you expose POSIX on Windows?

[_urga]

POSIX is an interface not an implementation.

[bzbarsky]

> but I refuse to touch Javascript with a ten-foot pole.

Why? Honest question here: what are the problems that are making you unwilling to even try it? Is performance the main problem?

> just think of it as opening up the "standard native code"

As long as the browser is running on a small set of target hardware architectures. And everyone else gets locked out, right?

If PNaCl ever happens, that might change, but at the moment that's how NaCl works: you tie your "web page" to a particular set of hardware architectures when you use it.

[daeken]

> Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE.

So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.

[jre]

I don't think NaCl is targeted at web devs that are comfortable developing in the browser. It's targeted at the other devs that aren't comfortable with JS and who write C++ (or other) code (like in games or other graphic-intensive stuff).

[smoyer]

I agree ... and I'll extend it by asking why you'd "dis" the other languages he attacks. Once again the old adage is proved: "When all you have is a hammer, everything looks like a nail". Let's get over the JS insecurity, admit it's useful for some tasks and that it sucks for others and get on with some useful discussion about when each of those statements is true.

[jon6]

Also Nacl supports threads while emscripten does not. For a large set of applications (including my own games) this is a deal breaker to using emscripten.