4 ms·

> 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

> 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).
    - cmccabe 14y ago
      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 14y ago

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).
  - cmccabe 14y ago
    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 14y ago