4 ms·

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore. Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them. The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight? For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval) Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU. Something like DVM, or a bytecode specifically designed for JS would be better I think.

thristian 15y ago
There's a difference between open-source software and an open-source project. For example, compare the PostgreSQL and MySQL databases. Both are released under an open licence, but PostgreSQL is developed openly on a mailing-list and anyone can step up and contribute, while MySQL is developed privately by an organisation, with occasional source releases. No single entity has a majority control of PostgreSQL, but Oracle has a pretty firm grasp of MySQL. Likewise, even though Dart is supplied under an open licence, it remains to be seen whether it's operated more like PostgreSQL or more like MySQL. As I understand it, the V8 project is somewhere between the two, and Android is way up the MySQL end of the spectrum. Based on what Brendan has said, I doubt Mozilla would want such a large part of their platform based on a black box they can't control, and I can't really imagine Microsoft doing it. I don't think your Unix example is quite fair; the number of Unix systems on the planet is orders of magnitude smaller than the number of web-connected system. Even so, there's still a lot of people working with Darwin in the guise of iOS and OS X, and there's a decent number of computers running non-Unix-based operating systems too. I'll confess I'm not too familiar with the exact changes planned for ES.next, I just recall Brendan saying that improving JS as a primary language and as a compilation target were major goals in the ECMAScript committee. Maybe it's not there yet, but it can get there faster than it will take to add performant Dart VMs to every browser. Brendan talks about the specific issue of a standardised bytecode here: http://news.ycombinator.com/item?id=1905291 http://news.ycombinator.com/item?id=1905291 (as part of an entire thread on the topic)
ootachi 15y ago
"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this? "could be atleast partially statically optimized for a particular device platform" I don't want this at all. That's too close to ActiveX for comfort. "wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)" You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.
- jasonmc 15y ago
  "You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.
  - ootachi 15y ago
    No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation. And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too. [1]: http://java.sun.com/docs/white/langenv/Security.doc3.html http://java.sun.com/docs/white/langenv/Security.doc3.html
    - jasonmc 15y ago
      Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.

thristian 15y ago

There's a difference between open-source software and an open-source project. For example, compare the PostgreSQL and MySQL databases. Both are released under an open licence, but PostgreSQL is developed openly on a mailing-list and anyone can step up and contribute, while MySQL is developed privately by an organisation, with occasional source releases. No single entity has a majority control of PostgreSQL, but Oracle has a pretty firm grasp of MySQL. Likewise, even though Dart is supplied under an open licence, it remains to be seen whether it's operated more like PostgreSQL or more like MySQL. As I understand it, the V8 project is somewhere between the two, and Android is way up the MySQL end of the spectrum. Based on what Brendan has said, I doubt Mozilla would want such a large part of their platform based on a black box they can't control, and I can't really imagine Microsoft doing it. I don't think your Unix example is quite fair; the number of Unix systems on the planet is orders of magnitude smaller than the number of web-connected system. Even so, there's still a lot of people working with Darwin in the guise of iOS and OS X, and there's a decent number of computers running non-Unix-based operating systems too. I'll confess I'm not too familiar with the exact changes planned for ES.next, I just recall Brendan saying that improving JS as a primary language and as a compilation target were major goals in the ECMAScript committee. Maybe it's not there yet, but it can get there faster than it will take to add performant Dart VMs to every browser. Brendan talks about the specific issue of a standardised bytecode here: http://news.ycombinator.com/item?id=1905291 http://news.ycombinator.com/item?id=1905291 (as part of an entire thread on the topic)

ootachi 15y ago

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this? "could be atleast partially statically optimized for a particular device platform" I don't want this at all. That's too close to ActiveX for comfort. "wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)" You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.

jasonmc 15y ago
"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.
- ootachi 15y ago
  No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation. And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too. [1]: http://java.sun.com/docs/white/langenv/Security.doc3.html http://java.sun.com/docs/white/langenv/Security.doc3.html
  - jasonmc 15y ago
    Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.