7 ms·

Interview with Lars Bak about Dart

36 points by bitcartel 14y ago

lucian1900 14y ago
While it's much more consistent than JavaScript, I find Dart to be a pretty bad language. It's sad that it doesn't learn from the failures of Java and JavaScript. Hopefully the VM will be easy to target from other languages.
- pekk 14y ago
  When I very briefly looked at Dart I found it to have a Java-ish flavor. Is that the problem you had? Can you mention a little of what makes Dart pretty bad?
  - lucian1900 14y ago
    I guess it's more disappointment than anything else. I find: - syntax to be a step backwards. Useless tokens everywhere, distinction between expressions and statements, no macros or some other extension mechanism. Docstrings-in-comments. Silly operators like &&. Increment operators, even with post/pre distinction! The switch, with yet another form of fall-through. "new" keyword for creating objects. I thought we'd all learned that C/Java syntax is stupid. - the distinction between production and development mode to be dangerous (no asserts in production). Behaviour differs enough to be confusing - anything can be thrown. Why even bother with an exception type then? - I see no value in specifying types if they aren't actually checked all the time. Generics are equally optional. We'll see if this experiment proves me wrong, but I doubt it. - constructors are complex and confusing. For some reason they don't get inherited - static methods. They aren't class methods, so why even bother? The docs even recommend not using them - peculiar boolean context. For some reason, everything is falsy except for true - no ADTs or at least non-nullable types On the other hand, it gets many other things right (module system, less crazy semantics than JavaScript, properties, operator methods, libraries are saner, etc.). It's just sad that it could've actually been a nice language.
    - pekk 14y ago
      Thanks!
    - jrockway 14y ago
      Dart is basically Java Script. It's not called that because some language completely unrelated to Java called itself that already :) To reply to some of your points: The syntax is designed to look like Java. It's there for Java programmers, not to be the best syntax ever. (new is important, however, because you can also create objects with const.) Yeah, it's not Python. Production and development mode are a common optimization in other languages. Remember: type annotations in Dart cannot, by design, change the behavior of the application. So in production mode, that part of the language spec is enforced. Static analysis tools, etc., are free to do whatever they want, however. I'd rather catch type errors at code review time rather than at runtime in production anyway. The constructors make sense to me. They work like Java, and there is better syntax for initializing fields (which is all I ever do in constructors anyway). Ultimately, it's Java in client-side form. Compare it to GWT, not Python or Haskell.
      - lucian1900 14y ago
        Right, and I think that's precisely what's wrong with it. It's only slightly better than both Java and JavaScript, but not an appreciable improvement otherwise. I'd have hoped for a more interesting language for such an interestingly pedigreed VM.
        jrockway 14y ago
        As a programming language, Dart isn't particularly interesting, but as a tool, it's very interesting. You can actually write client code that can be reused: as your web UI, as your smoke test, as a Chrome extension, etc. And it's easy to write tests for, with Hamcrest-style matchers.
- azakai 14y ago
  > Hopefully the VM will be easy to target from other languages. I doubt that would help you. The Dart VM is tailored to the Dart language (which in turn was designed with the thought of compiling to JS in mind), it would be suboptimal for anything else. Exceptions happen, but they are very rare.
  - taybin 14y ago
    I remember when the JVM was tailored to the Java language and people declared it too hard to have other languages compile to it.
    - azakai 14y ago
      Well, the fact is that other languages do not run on it at the full speed they could with their own custom VM. It's been many years of effort and dynamic languages on the JVM still do not compete with native dynamic language VMs. But yes, for languages like Scala etc., they run quite well on the JVM, well enough for sure.
taeric 14y ago
While I'm not opposed to speed improvements just happening. I'm somewhat curious to know how often the processing power of javascript is the limiting factor in an application. That is, I can't see this being too compelling for the majority use case of browsers. Without that, I can't see not having Dart support being an issue for competing browsers.
fourstar 14y ago
I'm not a fan of Dart, however Lars Bak was a guest on Javascript Jabber some time back: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/ http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba... Interesting listen.
kibwen 14y ago
Does anyone who follows Dart development have any hard benchmark figures? The only mention of performance in the article is distressingly light on numbers: "Bak now reckons Dart runs 30 per cent faster on Google's V8 than JavaScript under the Richards operating system kernel simulation benchmark and under the DeltaBlue benchmark – two standards used at Google." What's perhaps most important for Dart at this stage isn't how much faster its VM is than Javascript; what matters is how its generated Javascript performs relative to hand-written Javascript in browsers without a Dart VM.
- mraleph 14y ago
  [disclaimer: I'm a member of the Dart project working on the VM] These two benchmarks are publicly tracked at http://www.dartlang.org/performance/ http://www.dartlang.org/performance/ Dart VM is used to provide smooth developer experience and can operate standalone on the server side (there is dart:io library) which makes its raw performance quite important, from my point of view.
  - kibwen 14y ago
    Thanks, this graph is perfect. (For everyone else, note that you can click and drag on the graph to go back in time.) > Dart VM is used to provide smooth developer experience and > can operate standalone on the server side (there is dart:io > library) which makes its raw performance quite important, > from my point of view. The server side is a bit irrelevant here; nobody's pretending that Dart's ever going to get traction on the server side if it doesn't first have a strong stake on the client side. And if I'm pitching to my team that we should use Dart for our web applications, I need to know that my performance won't be dreadful on the majority of installed browsers in the world. One more question: is there a reason you only run two of the Octane benchmarks, rather than the entire suite? More data points would make for a more convincing argument.
    - mraleph 14y ago
      > is there a reason you only run two of the Octane benchmarks As the FAQ states at the very bottom of the page: Porting benchmarks correctly takes time. As more benchmarks become ready, we will publish more charts. Some Octane benchmarks are quite hard to port either because they are very big (PDF.js), generated by some sort of compiler (e.g. Mandreel and EarleyBoyer) or exercise things that might not necessarily have any direct translation to Dart (RayTrace is using class emulation code take from prototype.js).
DanWaterworth 14y ago
> and should generate fewer bugs – called side effects I know this was unintentional, but I agree, for the most part side effects are bugs.

36 points by bitcartel 14y ago

lucian1900 14y ago

While it's much more consistent than JavaScript, I find Dart to be a pretty bad language. It's sad that it doesn't learn from the failures of Java and JavaScript. Hopefully the VM will be easy to target from other languages.

pekk 14y ago
When I very briefly looked at Dart I found it to have a Java-ish flavor. Is that the problem you had? Can you mention a little of what makes Dart pretty bad?
- lucian1900 14y ago
  I guess it's more disappointment than anything else. I find: - syntax to be a step backwards. Useless tokens everywhere, distinction between expressions and statements, no macros or some other extension mechanism. Docstrings-in-comments. Silly operators like &&. Increment operators, even with post/pre distinction! The switch, with yet another form of fall-through. "new" keyword for creating objects. I thought we'd all learned that C/Java syntax is stupid. - the distinction between production and development mode to be dangerous (no asserts in production). Behaviour differs enough to be confusing - anything can be thrown. Why even bother with an exception type then? - I see no value in specifying types if they aren't actually checked all the time. Generics are equally optional. We'll see if this experiment proves me wrong, but I doubt it. - constructors are complex and confusing. For some reason they don't get inherited - static methods. They aren't class methods, so why even bother? The docs even recommend not using them - peculiar boolean context. For some reason, everything is falsy except for true - no ADTs or at least non-nullable types On the other hand, it gets many other things right (module system, less crazy semantics than JavaScript, properties, operator methods, libraries are saner, etc.). It's just sad that it could've actually been a nice language.
  - pekk 14y ago
    Thanks!
  - jrockway 14y ago
    Dart is basically Java Script. It's not called that because some language completely unrelated to Java called itself that already :) To reply to some of your points: The syntax is designed to look like Java. It's there for Java programmers, not to be the best syntax ever. (new is important, however, because you can also create objects with const.) Yeah, it's not Python. Production and development mode are a common optimization in other languages. Remember: type annotations in Dart cannot, by design, change the behavior of the application. So in production mode, that part of the language spec is enforced. Static analysis tools, etc., are free to do whatever they want, however. I'd rather catch type errors at code review time rather than at runtime in production anyway. The constructors make sense to me. They work like Java, and there is better syntax for initializing fields (which is all I ever do in constructors anyway). Ultimately, it's Java in client-side form. Compare it to GWT, not Python or Haskell.
    - lucian1900 14y ago
      Right, and I think that's precisely what's wrong with it. It's only slightly better than both Java and JavaScript, but not an appreciable improvement otherwise. I'd have hoped for a more interesting language for such an interestingly pedigreed VM.
      - jrockway 14y ago
        As a programming language, Dart isn't particularly interesting, but as a tool, it's very interesting. You can actually write client code that can be reused: as your web UI, as your smoke test, as a Chrome extension, etc. And it's easy to write tests for, with Hamcrest-style matchers.
azakai 14y ago
> Hopefully the VM will be easy to target from other languages. I doubt that would help you. The Dart VM is tailored to the Dart language (which in turn was designed with the thought of compiling to JS in mind), it would be suboptimal for anything else. Exceptions happen, but they are very rare.
- taybin 14y ago
  I remember when the JVM was tailored to the Java language and people declared it too hard to have other languages compile to it.
  - azakai 14y ago
    Well, the fact is that other languages do not run on it at the full speed they could with their own custom VM. It's been many years of effort and dynamic languages on the JVM still do not compete with native dynamic language VMs. But yes, for languages like Scala etc., they run quite well on the JVM, well enough for sure.

taeric 14y ago

While I'm not opposed to speed improvements just happening. I'm somewhat curious to know how often the processing power of javascript is the limiting factor in an application. That is, I can't see this being too compelling for the majority use case of browsers. Without that, I can't see not having Dart support being an issue for competing browsers.

fourstar 14y ago

I'm not a fan of Dart, however Lars Bak was a guest on Javascript Jabber some time back: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/ http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba... Interesting listen.

kibwen 14y ago

Does anyone who follows Dart development have any hard benchmark figures? The only mention of performance in the article is distressingly light on numbers: "Bak now reckons Dart runs 30 per cent faster on Google's V8 than JavaScript under the Richards operating system kernel simulation benchmark and under the DeltaBlue benchmark – two standards used at Google." What's perhaps most important for Dart at this stage isn't how much faster its VM is than Javascript; what matters is how its generated Javascript performs relative to hand-written Javascript in browsers without a Dart VM.

mraleph 14y ago
[disclaimer: I'm a member of the Dart project working on the VM] These two benchmarks are publicly tracked at http://www.dartlang.org/performance/ http://www.dartlang.org/performance/ Dart VM is used to provide smooth developer experience and can operate standalone on the server side (there is dart:io library) which makes its raw performance quite important, from my point of view.
- kibwen 14y ago
  Thanks, this graph is perfect. (For everyone else, note that you can click and drag on the graph to go back in time.) > Dart VM is used to provide smooth developer experience and > can operate standalone on the server side (there is dart:io > library) which makes its raw performance quite important, > from my point of view. The server side is a bit irrelevant here; nobody's pretending that Dart's ever going to get traction on the server side if it doesn't first have a strong stake on the client side. And if I'm pitching to my team that we should use Dart for our web applications, I need to know that my performance won't be dreadful on the majority of installed browsers in the world. One more question: is there a reason you only run two of the Octane benchmarks, rather than the entire suite? More data points would make for a more convincing argument.
  - mraleph 14y ago
    > is there a reason you only run two of the Octane benchmarks As the FAQ states at the very bottom of the page: Porting benchmarks correctly takes time. As more benchmarks become ready, we will publish more charts. Some Octane benchmarks are quite hard to port either because they are very big (PDF.js), generated by some sort of compiler (e.g. Mandreel and EarleyBoyer) or exercise things that might not necessarily have any direct translation to Dart (RayTrace is using class emulation code take from prototype.js).

DanWaterworth 14y ago

> and should generate fewer bugs – called side effects I know this was unintentional, but I agree, for the most part side effects are bugs.