[simonster]

It's not just that. It's that there's no concept of a vector or matrix at all, and no operator overloading to allow these concepts to be introduced into the language in an idiomatic way. You could put these things into a bastardized JavaScript JIT, but that seems at least as awkward as Julia.

[btilly]

http://coffeescript.org/ has demonstrated how to fix that problem.

If the underlying engine is fast, a more convenient syntax can be introduced.

[simonster]

I thought about this a little bit, and I don't think this would be very trivial. CoffeeScript is designed to map easily onto JavaScript. A transcompiler that compiles JavaScript with matrix extensions to performant plain JavaScript would likely be significantly more complex than the CoffeeScript transcompiler.

Consider that you want to translate the matrix operation A * B into A.times(B). You have two options:

1) Figure out what's a matrix before runtime, using static type inference. 2) Translate the code into JavaScript that determines whether to treat the code as a matrix at runtime.

In the first case, you don't need a JIT at all. JITs exist largely because you can't do perfect type inference in dynamic languages. If you can do perfect type inference on all acceptable code (a la RPython), or if you require type annotations, you can compile straight to C or machine code.

In the second case, you take a speed hit of 25-50% on scalar operations for the guard, at least in modern versions of SpiderMonkey and V8 (see http://jsperf.com/cost-of-multiplication-via-function).

You can probably get acceptable performance out of combining static type inference with guards. My understanding is that this is what SpiderMonkey does internally. But at this point, it might be easier to integrate your functionality into an existing JIT than to write your transcompiler with type inference, particularly since you will have to implement matrix and vector ops inside the JS engine to achieve acceptable performance anyway.