Introduction to Dart VM | Hacker News Reader

Introduction to Dart VM

mrale.ph

109 pointsskybrian27 comments

I've always had the hint that dart was a technological marvel, but then when i look at the dart language itself compared to today's language (rust & swift for example) i feel a bit underwhelmed.

And the worst part is what i feel was the first environment outside erlang to get real actor-like concurrency is now barely mentionning actors in its documentation. It looks like they dumbed down the recommended server architecture to event-loop style to make it more accessible, instead of going full speed on actors.

Please correct me if i'm wrong..

I am not a language designer myself, but I think "avoid overwhelming" was an explicit idea behind initial design of Dart. Yes, this led to a language that some might consider boring, but it also led to a language that a lot of people can easily pick up and use (with little surprise and reasonable amount of fun).

There are few things that I would like to have in Dart (ADT and pattern matching for example), but otherwise I actually think its a fun language to program in.

> And the worst part is what i feel was the first environment outside erlang to get real actor-like concurrency is now barely mentionning actors in its documentation.

Dart went through a lot of turmoil in the past few years, but now that this turmoil is over we hope to explore concurrency story again.

Dartino (which was a dialect of Dart targeting IOT devices) had really fun concurrency story centered around lean isolates, coroutines and fast message passing based on deeply immutable data and we think there might be something here that we could incorporate into Dart proper.

I also agree with a desire for ADT and pattern, and also some better handling of Null (see Kotlin).

But I also agree that it's a very unsurprising language, in a good way.

Non-nullability is actually being actively worked on[1]. Currently language team is working on specifying the feature and figuring out the path towards it.

[1] https://github.com/dart-lang/language/issues/110

That's great to hear, thanks for pointing it out.

Thanks for the excellent write up and your work on Dart. After the long hiatus, I'm excited to see the language proposals in https://github.com/dart-lang/language, but I haven't seen anything in there regarding concurrency.

There is the "static immutability" proposal[1] which is related to concurrency. However it is correct that there is no single issue that just says "Make Concurrency Awesome".

I believe that we already have necessary building blocks (isolates), we just need to make concurrency via isolates efficient and ergonomic.

However it is still very early, so I don't have much else to share.

[1]: https://github.com/dart-lang/language/blob/master/working/01...

Ah, yes, I had read that previously. That's a big one and will be a game changer, including improving concurrency.

I might have to give Dart another look. The things that made me leave were:

- abandoned Dart VM in chrome (maybe WebAssembly can help here?) - inconsistencies between browser and VM Dart (number sizes is a big one) - long compile times - difficulty going between Dart and JavaScript

This was years ago (around the time Dartium was abandoned), so perhaps things have changed for the better. However, at this point, JavaScript has gotten better, so I'm not as interested in another compile-to-js language.

Dart language is not stagnant https://github.com/dart-lang/language

It seems odd to compare to dart with rust. That's like comparing C# or Java to rust. They aren't really competing in the same sphere.

Swift seems heavily inspired by dart (dart being the older of the two). If you remove things like reference counting that were added because of interopt with objective-C, then the similarities between the languages greatly outweigh the differences (in my view at least).

I'm on the Dart team.

> when i look at the dart language itself compared to today's language (rust & swift for example) i feel a bit underwhelmed.

My personal opinion is that Dart right now is a very mature implementation of an OK language. The original language designers were very conservative in the design of the language. In their hearts, they really wanted to make another Smalltalk — a very minimal, dynamic, object-oriented scripting language. But they felt that to be successful, it needed to be painted in a veneer of Java-esque syntax and have some sort of static type system. I don't think the designers ever really loved either of those aspects.

This is a big part of why Dart's original type system was optional and an unsound. It was intended to be just enough types to satisfy people who want types, without cluttering up the VM implementation with concerns around static types. This made sense when the initial goal was to have a VM directly in the browser that ran Dart programs from source. When you run from source on the end user's machine, there isn't really a good time to run a static type checker.

A lot has changed since then:

* The initial designers have moved on to other things. Lars will tell you he's a "1.0 guy" and shepherding a long-running language committee isn't his thing. I think the projects they're working on now are much closer to their hearts. It's hard to do a great job on something you aren't personally enthused by, so this is good for everyone.

* We aren't trying to get the VM in Chrome. I think this is overall a good thing. It means that all execution paths for Dart involve a compiler running on the developer's machine.

These two pieces make it much easier to move Dart to be a modern, expressive, statically-typed language, which is much more inline with what users have been asking for. The biggest example of this is Dart 2, which replaced the old optional type system with a rich, sound static type system with generic methods and type inference.

We also have a really good (I think) language team that is excited to move the language forward and make users happy. We're working on non-nullable types. We're making collection literals more expressive with spread ("...") and control flow.

Now that we have a real static type system that's part of the language, it enables us to hang language semantics off the types. For example, we're adding set literals right now. Those use the same curly brace delimiters as map literals. That makes an empty set/map ("{}") ambiguous. Fortunately, we can rely on the surrounding type context to disambiguate in most cases. We couldn't do that in Dart 1. This also puts on the table features like extension methods that rely on the static type system.

So, my hope is that over time, we'll be able to catch up and get to a point where the language itself is really positively exciting for people. We have some work to do to get there, but I think we're moving in the right direction and faster than we have before.

I think Dart was a result of optimizing JavaScript VM and learning about the cons of language which are hard to optimize for JS VM then getting rid of them.

Perhaps there is the option of transpiling from a different language to Dart?

Use Kotlin instead.

The article is clearly about the Dart VM...

This part on the unoptimized vs optimized code looks interesting:

Some functions contain very long running loops, so it makes sense to switch execution from unoptimized to optimized code while the function is still running. This process is called on stack replacement (OSR) owing its name to the fact that a stack frame for one version of the function is transparently replaced with a stack frame for another version of the same function.

That is fairly classical thing to do - a lot of VMs, including JVM and JS VMs do OSR.

Replacing the whole method/function seems pretty straight forward. Any good JS/JVM articles on how code is replaced mid-function?

Edit: I see the article does mention IL deoptimization IDs. I assume those are used as "anchors" to know where to continue with the optimized rest of the loop.

Yes, your intuition is correct. The way it works in Dart VM is like so:

Each loop has an interruption point somewhere (e.g. in the header). If a very hot loop is found VM would enter runtime at that interruption point, where it would synchronously initiate compilation of an optimized version of the function for OSR at this particular interruption point.

After unoptimized IL is contsructed it is "shaken": a matching interruption point is found in the graph and everything not reachable from it is shaken (which drops all code before the loop).

After then the graph is transformed a bit - for each local variable alive at the interrupt point we introduce artificial parameter - so that we could simply treat OSR substitution kinda like a call.

Then graph is optimized and compiled.

Finally when we return back to the original unoptimized code we would do a tail call to the new optimized version.

(I will cover this in the "Introduction to Dart VM" in more details and with some drawings, when I reach this).

Can dart be evaluated within the browser? I’ve been looking for a language which can be executed within the browser (without needing a connection to any server).

I would like to write some blog posts explaining technical concepts and provide executable, interactive code. As far as. I can tell, currently JavaScript is the only language for the job. All languages which transpile to js seem to require (out of browser) command line tools

Dart was originally designed as a JS 'replacement', designed to supplant it. The talked about browsers executing it directly, but as a transition step compile-to-JS has always been a first class citizen for Dart.

Now of course no language is going to replace JS, it's going to be compile to WASM or JS, and Dart is now focused on things like Flutter where it is used in a 'Ahead of Time' compiled form.

dart2js tool can be used in the browser, I believe this uses it: https://dartpad.dartlang.org/

It also has dart dev compiler which compiles much faster to more modern JavaScript: https://webdev.dartlang.org/tools/dartdevc

I think probably one of the most advanced languages in that respect is ClojureScript. ClojureScript is fully self hosting and you can 'eval' in the browser.

I don't really use ClojureScript, but it was a milestone that took a couple of years of leg work to get going.

ClojureScript is also in wide production use, I have not seen another compile to JS language that works as well.

dart2js is written in Dart so you can use it to compile itself and then run in browser.

OCaml/ReasonML could be evaluated in browser without a connection to a server. I built this little project to demonstrate the ability: https://sketch.sh

You can use the Typescript transpiler directly in a browser.

Reply on news.ycombinator.com