Comment by haberman | Hacker News Reader

Comment by haberman | Hacker News Reader

Parent Full thread

> 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.

"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.

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.

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).

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.

There's nothing to "support" yet with PNaCl. It's still at the "we have no idea how to make this work" stage, last I checked.

And if it _could_ be gotten to work, you still haven't addressed why Mozilla should be willing to get on the Pepper "upgrade to keep up with all this unspecified stuff we're changing" treadmill.

It's not just scars from Flash and ActiveX; it's a distinct reluctance to bet everything on a technology you have 0 control over, and which one of your direct competitors controls completely. Now why would Mozilla be hesitant to do that? You tell me.

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.

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.

You're confusing "proprietary software" and "proprietary technology". They're not the same thing.

There are lots of examples of open-source software implementing proprietary technologies of various sorts (example: x264). There are lots of examples of proprietary software implementing open technologies of various sorts (example: Opera).

I'm not talking about the licensing model for the NaCl source code; I'm talking about the openness or not of the entire NaCl technology stack.

As far as folks at Mozilla go, I think they might point you at http://www.readwriteweb.com/archives/how_to_spot_openwashing...

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?

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

I know +1's don't help but ditto from me.

I haven't had time to use TS much yet but the combination of structural type system (not needing to inherit from IFoo, if you have the members it's enough) and optional typing look like exactly what I want.

Hopefully this pays off in terms of not only self-descriptive code but also greater support for refactoring tools.

In many ways, TypeScript is the "anti-Dash" (see leaked Dart memo). It builds on ES6. It does not inject novel runtime semantics. It just checks annotations _a la_ JSLint. Smart!

Reply on news.ycombinator.com