Earlier quoted context omitted.
Ah I see I should have said "Google" where I said "NaCl". My mistake.
You're doing better! But no, I don't "hate" Google. Big companies and big groups of people in general have inherent morally failure-prone properties. Google fights these, and in many ways still manages "don't be evil". Heavy-handed and one-sided strategies and tactics may be odious, I may "hate" them -- you should too if they're not well-justified and likely to prevail -- but that's not the point of this exchange, wh…
The State of JavaScript - Brendan Eich
261–266 of 266 posts
Re: The State of JavaScript - Brendan Eich
#262Earlier quoted context omitted.
I always reply when I have something worth saying. "Hate" is the wrong word. There's nothing to hate in a well-done SFI-enforcing compiler. I admire the R&D effort. We -- bad old Mozilla, including evil-me -- are seriously considering using NaCl (not Pepper) for SFI in native code parts of Servo. No "hate" here, so do try to grow up: "You hate NaCl" is just weak, beneath you, as an analysis of motives and causes. Let…
That's why you have been supporting Emscripten with... just one developer, it's creator? Shouldn't there be a whole team towards this goal you envision? Currently emscripten should have the amount of people three.js has.
Also, Emscripten has a strong github community. Unlike Google we can't afford to pay everyone who might be needed -- we also prefer not to if we can build a wider community from day one.
Re: The State of JavaScript - Brendan Eich
#263Earlier quoted context omitted.
You're doing better! But no, I don't "hate" Google. Big companies and big groups of people in general have inherent morally failure-prone properties. Google fights these, and in many ways still manages "don't be evil". Heavy-handed and one-sided strategies and tactics may be odious, I may "hate" them -- you should too if they're not well-justified and likely to prevail -- but that's not the point of this exchange, wh…
Do you think the current status of Emscripten justifies your words? We'd all like to believe that.
These are focus areas of the team I just mentioned.
Re: The State of JavaScript - Brendan Eich
#264Earlier quoted context omitted.
Do you think the current status of Emscripten justifies your words? We'd all like to believe that.
The challenge now is more on the JS VM side, optimizing the Emscripten-generated idioms and the typed array memory model. Also, longer-term, we're working on JS language evolution via Ecma TC39. These are focus areas of the team I just mentioned.
Thanks though for your answer.
Re: The State of JavaScript - Brendan Eich
#265Earlier quoted context omitted.
I have a different writing style from Brendan, but I don't think there is any significant substantive difference between what he said in this thread and what I said almost 2 years ago. (Although, the fact that PNaCl is still an experiment and not the mainstream of NaCl nearly two years after I wrote my comment should be further cause for concern.)
The significant substantive differences, to me as a reader, are: - You don't make final-sounding judgments like "never" or "non-starter" that preemptively reject any future evolution of the technology. - Your criticisms are highly pragmatic and specific, such that it is clear what hurdles the technology would have to clear to address them, and you don't close the door to the idea that they could (even if it seems unl…
The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state.
My "highly pragmatic and specific" criticisms seem to me like they say the same thing as Brendan's original slide bullets, just with more detail. I did not mention "no view source", but I agree that is a significant downside, if not necessarily as much of a showstopper as the others. Being a single-vendor-controlled technology is the biggest showstopper.
Another big issue that I didn't mention, and which I think also aligns with Brendan's criticisms, is that adding a major new technology to the web platform requires tremendously compelling use cases and a good argument that they cannot be handled with existing technologies. I don't think that case has really been made for NaCl.
And yes, I did jokingly coin the term "ActiveG" to refer to NaCl. Though I believe it was another wag who later referred to Dart as "GBScript".
Re: The State of JavaScript - Brendan Eich
#266Earlier quoted context omitted.
The significant substantive differences, to me as a reader, are: - You don't make final-sounding judgments like "never" or "non-starter" that preemptively reject any future evolution of the technology. - Your criticisms are highly pragmatic and specific, such that it is clear what hurdles the technology would have to clear to address them, and you don't close the door to the idea that they could (even if it seems unl…
Wow, I didn't notice that the thread continued for so long after I posted. The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state. My "highly pragmatic and specific" criticisms seem to me li…
For what it's worth I thought you were from Mozilla when I wrote my post, not that it matters that much either way.
I think you made some substantial points that were not covered in Brendan's slides, specifically:
- A standard with only one implementation is de facto controlled by one entity. This is a great point, and different than Brendan's point "defined by implementation." Brendan's criticism would be solved simply by standardizing (P)NaCl under multi-party governance, which I fully expect Google will do at some point. [0] Your criticism is not solved unless it is actually practically feasible for someone else to implement that standard.
- Relying on binary-level validation of binary code has a lot of attack surface. This is a great point that I've seen others make, though I believe it is being addressed (perhaps since you wrote your message) by having multiple layers of defense (ie. also running in a separate process inside a ptrace sandbox).
It doesn't bother me that you joke around with your friends by calling it "ActiveG," because in the context of serious discussion you acknowledge that it has "a better attempt at security design than ActiveX." It does bother me when others seriously compare the two, as if a completely unsandboxed execution environment can be compared to a serious attempt at sandboxing.
In any case, now that it supposed to be shipping soon (http://news.cnet.com/8301-1023_3-57534803-93/google-offers-l...) we should get a better chance to see if it truly can demonstrate a compelling improvement over JavaScript.
[0] Just wanted to mention that though I work for Google I am not involved in (P)NaCl and have no inside information about it.