Interview with Lars Bak about Dart

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

Let me sketch out my own interpretation of the problem.

JavaScript programs lack declarative structure.

There is no way to declare a class with a fixed set of fields and methods. Instead JavaScript program creates functions and sets up their prototype property as it executes.

No way to declare a module. Instead developers create and immediately invoke a nameless closure.

One can say that the structure (things that people view as "classes" and "modules") behind JavaScript program is the side-effect of this very program executing. There is no clear border between "structure initialization" and execution.

So the first issue arises: to snapshot something you need to guarantee that deserialized snapshot will result in the very same "structure" that would arise from executing this code from scratch. This imposes certain restrictions on the way the JavaScript code should be written and how its initialization should be laid out. If for example application starts interacting with DOM early in its "initialization" phase then this is hard to snapshot correctly.

But an opposite is true as well: other programs (scripts) executing in the same environment might affect the structure that JavaScript program weavers as it runs.

Consider for example the following code:

    function Point() {
    }
    Point.prototype.distance = function () { /* ... */ };

It might look like we could snapshot it and then unconditionally deserialize it into a Point function with a distance property on an object in its prototype property. But this is not true. If our deserialization does not happen in the clean environment (e.g. we are not the very first thing that is running on the page) then somebody can install "distance" property with a setter on the Object.prototype thus altering execution of our initialization entirely. This means that deserialization code must account for that.

So we have two points to care about:

(a) JS code must be written in a special way to benefit from snapshotting, serializer must bail out from the attempt to snapshot "unsound" initialization code;

(b) deserializer must ensure correctness when unpacking.

If you ensure that both hold then you can actually snapshot your JS code and benefit from it.

V8 in fact does this internally: some JavaScript builtins are written in JavaScript and "snapshotted" to speed up their initialization. But V8 snapshots are cutting corners:

- Point (a) is ensured manually. "Unsound" initialization code in builtins just leads to mysterious bugs. There is no verification, toolchain does not reject any code.

- Point (b) is guaranteed because deserializer is applied when the world is empty and untouched by the user code.

This is not something you can use for an arbitrary JS code AS IS... and filling up the gaps requires hard efforts on both VM and application side.

Dart does not have any problems like that because the structure behind the program is static. So snapshotting is simple to implement and it works for any application, not requiring any "restructuring" from the app developer.

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.

Thanks!

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.