HN Explorer

20 comments

[ 3.3 ms ] story [ 49.3 ms ] thread
munki
Sort of lost interest in Dart since they dropped the idea of integrating the VM into Chrome.
tosh
imho it makes sense to focus more on further improving dart2js to ensure it works really well across all JavaScript virtual machines and to make interop with JavaScript & TypeScript super smooth.

The Dart VM (as well as the Observatory) are fantastic. At Blossom (https://www.blossom.co) we currently use the Dart VM for command line tools but we're looking into using it on the server side as well.

I guess you were especially interested in the performance improvements that the Dart VM could bring if it was added to Chrome? I expect that we'll also see performance improvements for dart2js as JavaScript runtimes become better compilation targets (e.g. SIMD.js, BigInt, SoundScript, …).

The interesting thing here is that the Dart team can focus on other areas like …

* the standalone Dart VM

* fletch (an experimental mobile optimized runtime)

* Observatory

* async/await

* libraries (e.g. the new `test` package)

* analyzer (used for semantic code completion & warnings and powers IntelliJ, Eclipse, Sublime, Atom (soon), DartPad see https://dartpad.dartlang.org/)

* …

and many other things in the meantime. Getting the Dart VM into Chrome and have it play nicely with v8 is not trivial.

brodo
When there is no Dart VM in the browser I honestly don't see any advantage over TypeScript. Two VMs inside each other (with two garbage collectors) will always be slower and use more memory than just one. Additionally, you always need to ship the runtime with all your scripts. You also have to use FFI to interact with Javascript. All the advantages over plain JS you mentioned above are also present in TypeSctipt (or not needed).

There is also a nice discussion about TypeScript and Dart here: https://www.youtube.com/watch?v=5AqbCQuK0gM

wtetzner
> Two VMs inside each other (with two garbage collectors) will always be slower and use more memory than just one.

Is that how it works? I just assumed it would compile to JS and just use the JS garbage collector.

tree_of_item
It does compile to JS and use the JS garbage collector. The posting you're replying to is very misinformed.
tosh
As far as I understand you are also less likely to run into unpredictable performance (runtime bailing out) scenarios using Dart + dart2js.
tree_of_item
What second garbage collector are you referring to? There aren't "two VMs inside each other" when you compile with Dart.

I think Dart's biggest weakness is the fact that most web developers don't understand how compile to JS languages work and go around spreading all kinds of silly FUD. I remember posting a Gist on the day of Dart's release showing the compiled runtime, and the thread exploding with hundreds of comments from people laughing at the fact that it was 17,000 lines or so, nevermind the fact that that's how every compile-to-JS language that's more than a thin skin over JS semantics works.

tosh
TypeScript is definitely an improvement over JavaScript but it is less ambitious compared to Dart (something that is also mentioned in the video you linked to).

Dart is more than 'just' a language with cleaner semantics (which is already an improvement upon TypeScript which still is closely tied to JavaScript re type coercion problems etc).

See my other posting. The Dart VM exists and can be used on the server side, for command line apps and in Dartium (fast dev cycle & debugging).

There is advanced tooling, a very clean standard library, a mobile optimized runtime, bundler inspired package management (pub), a well staffed team of people working on the analyzer and compiler toolchain and a lot of stuff surrounding "Dart the language".

stesch
I've read a comment somewhere that they are developing a new dart2js. Is this right?
tosh
The Dart team is working on a compiler called 'ddc' (Dart Dev Compiler)

https://github.com/dart-lang/dev_compiler

It currently targets ES6 and also comes with a more strict type checker.

Project goals:

* Effective static checking and error detection.

* A debugging solution for all modern browsers.

* Readable output.

* Fast, modular compilation of Dart code.

* Easy use of generated code from JavaScript.

ExpiredLink
He really means macros similar to the C pre-processor?

Dart is a modern dynamic language. Why should it need C-like macros?

tree_of_item
No, they're not C-like, as mentioned they're AST transforms instead of textual substitution.
randomfool
I disagree that Dart's code transformers are comparable to Macros- their intent is runtime optimization- take valid code which runs fine in the VM and optimize it for dart2js compilation.

This feels more like an advanced compilation feature than macros which are typically used to encapsulate a set of complex operations.

skybrian
Code transformers are more general than macros and I focused on one way to use them. I disagree that they're an optimization in this example, since the original code isn't being transformed but rather overridden with a separate implementation. It's more like overriding a method in a subclass; the intent is probably for the implementations to have equivalent behaviors, but the details differ and there can be bugs.

Just like when a method is overridden, the reader should be able to see that there are multiple implementations and understand how they work. If you want to understand performance, you need to look at the production implementation.

malkia
This reminds me of Turbo Pascal, where certain runtime functions can take variable arguments, yet the language does not allow defining such. It felt like magic.

Abother example is lisp, and yes lisp has the ultimate macro language (scheme, cl, clojure), and yet in Common Lisp there is the notion of "open coded" - certain builtin names are known to the compuler/interpreter and can do also magical things. That to be said certain implementations of C/C++ also have them.