> Dart will not be 2x (or more) faster than JS.

Why are you so sure of this? The people involved appear to be big believers that dynamic languages can be extremely performant provided they are designed with the VM in mind. LuaJit proves this out. A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C.

http://attractivechaos.wordpress.com/2011/01/23/amazed-by-lu...

http://lua-users.org/lists/lua-l/2009-06/msg00071.html

I think far too much emphasis is being placed on whether Dart replaces JS in the browser. Google would gain a huge amount by having a performant server-side language that can be tooled and compiled to JS for the client.

> A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C.

You are using outdated measurements. Up to date results:

http://attractivechaos.github.com/plb/plb-lang.png

http://attractivechaos.github.com/plb/

The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes from differences in language features (no debugger interruption support for generated code in LuaJIT2) and lack of certain optimizations (e.g. array bounds check elimination) in V8 [matmul_v2.lua used for measurements relies on ffi arrays which do not include bounds checks at all]. Code generated by both compilers is roughly equivalent (invariants hosted out of the loop, temporary double values are on xmm registers, etc). A bit more details: http://blog.mrale.ph/post/5436474765/dangers-of-cross-langua...

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?

JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode).

These all add some cost in either runtime guards, static analysis burdens, or a mix.

A new language could leave out most of these, but it would still want inheritance. Then the question would be: how useful is mutability along the inheritance chain, i.e. shadowing -- even if you remove 'delete'.

Beyond this, a new language or a JS extension (this is what the Dash memo rules out as un-possible, without evidence) could allow pinning down the shape of objects, even to include machine types such as int32, etc. That would allow for big speedups on certain benchmarks.