The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNIX (e.g. start reading here: http://en.wikipedia.org/wiki/Ten15), look at the resounding failure of Parrot to become a universal VM, look at the recent rebuttals at attempts to use LLVM as an architecture-independent format.

What benefit do you expect your "machine code" to have over JavaScript?

All the benefits that people proposing new web languages would impart. There are a good reasons why Google are proposing running Dart straight on their VM in Chrome. It will be faster, safer, easier to jit, easier to prove correct etc. Having a firm foundation would make it easier to innovate. Companies could still be encouraged to compete for faster and safer implementations.

The failure of Parrot to catch on has very little to do with the technology, nor the proposition of a general-purpose dynamic language VM. Parrot was simply in the wrong place at the wrong time (and it took too long to deliver). It also made the mistake of tying itself to an unfinished language spec. If they had concentrated on making a VM that could run Python, Ruby and Javascript they would have been in the right place at the right time when Perl 6 was finally ready to be implemented.

People are beginning to use Javascript and the V8 engine in a manner similar to the original Parrot proposal.

The time is right for a general-purpose IL so we can compile Coffeescript straight to the Javascript VM.

LLVM is being questioned by some because a) it isn't a VM it's just an IL so it is a compiler technology not a VM tech b) it is too low level to make the jitting of dynamic languages suitably efficient. LLVM is too low-level; Javascript is too high (and opinionated).

Judging innovation by precedence is always a bad idea.

I imagine for this web version of C -- and it should be a language, not a byte code format -- it would need to satisfy these properties:

- language constructs that map semi obviously to machine instructions (ie, you don't need to spend a lot of time guessing what "switch" or "while" or "struct" get turned into), while avoiding things that might not be so obvious. (What does a closure look like in assembly? Or a generator?)

- types that correspond to machine types

- some sort of predictable and low level memory model (without pointers, but with some sort of way to avoid garbage collection issues. Maybe something with reference counting)

Higher level constructs carry more semantics, that is why they are easier to verify/sandbox.

Sidenote: GC wouldn't prevent anyone from stealing a lot of resources. Either way you can ask for a lot of resources and not give them back.

* Yes I know fortran has a thing called a pointer, but it's a lot different.

Definitely.

> This is what Javascript is becoming and it isn't well designed for it.

Maybe... but what does a bytecode layer provide?

I wonder if something useful couldn't be written in JS that provides a thin service layer. I agree it's not ideal, but it's what we've got.

Google already have a few to-javascript compilers, including one for Dart... I expect they're already all over this.

If Javascript is good enough as an IL why does Dart bypass it in Chrome?

Because they decided that it was easier to make up a new language than improve the V8 implementation of ECMAScript, as far as I can tell.

And at least locally, for Google, that may be true. Whether it's true for the web as a whole is unclear.

Other ECMAScript implementors seem to think that V8 is not nearly as fast as an ES implementation could be and are working on proving their claims with actual running code...

Sure, but that's not going to happen in the next decade unless that IL is in Javascript.

e.g:

  Javascript → IL → Javascript

static bool isVm() { return 1234567890123456789 % 2 > 0; }

Funny enough in javascript 1234567890123456789 % 2 == 0.

[1] http://dartinside.com/2011/live-from-dart-launch/#liveblog-e...

CoffeeScript is pretty close. It just changes the syntax, but the type-system is the same.

All it is is a javascript like language with classes, interfaces, optional types, and some extra built in data structures. A new runtime, biggest obstacle being adoption, just for that seems a bit much.

It produces an "TypeError: 'undefined' is not an object (evaluating 'a[Ra]')" and "TypeError: 'undefined' is not an object (evaluating 'b.count')". The console was a bit hard to get to with webkit2 taking up 100% of a cpu and all that.

I honestly have no idea where the world is headed to these days...

On the other hand, you still don't have the great community like for instance ruby has. Charles Nutter has created a static typed ruby like language, called Mirah, which looks similar.

     the main benefit is catching errors early

This enables certain techniques that are very productive, and totally different from what you would do in a language like Haskell, which does have full-type inference.

I also do not think a static language would work as a client-side in-browser language, simply because of the nature of browsers and the web. Such a language needs runtime introspection and even types created at runtime like air. For in-browser stuff I also prefer eval() over static-typing any day of the week.

eval() is shown to be usable in a static typing environment by some of Don Stewart's papers, though it does take more effort on the language implementors' side.

Reflection is achieved in Haskell, for example, using reflective type-classes (such as Typeable and Data).

Above should read: "There's no real conflict"

[1] https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja... [2] http://clojure.github.com/clojure/clojure.core-api.html#cloj... [3] http://clojure.github.com/clojure/clojure.core-api.html#cloj...

I'm not sure what Proxy is used for -- but it sounds like Template Haskell can probably implement it?

defrecord seems like it refers to defining new types at runtime -- which is also possible via either late type-check or Template Haskell.

  String | `a < SimpleListFilter | (String, `b < FieldListFilter)

Server-side execution? I thought Go was their systems programming language? It sure sounds like they're competing rather than complementing each other.

There's room, I just don't get why Google would promote two of its own very similar languages for the same purpose at the same time.

Think server side web programming.

Is PHP/Ruby et al a "systems programming language"?

It also seems like another incarnation of GWT, which, I heard, google abandoned.

"Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser."

What am I missing?