8 ms·

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

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 14y ago
> 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/untrusted_dlcp/research.google.com/en/us/pubs/archive/37204.pdf 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 14y ago
  "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 14y ago
    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 14y ago
      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 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 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).

haberman 14y ago

> 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/untrusted_dlcp/research.google.com/en/us/pubs/archive/37204.pdf 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 14y ago
"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 14y ago
  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 14y ago
    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 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 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).