So far the Dart implementors don't even implement their spec correctly and some of the completely broken things in Javascript have been retained. And some new ones have been added too.

I'm absolutely stupified that their spec claims integers are not limited to 32 or 64 bits but only limited by the size of memory on the machine. Not only is that not true (they've just used the completely broken Javascript double precision floats), but it isn't even sensible. You cannot make bignums anywhere near as efficient as machine words.

They've even thrown away some of the really brilliant things in Javascript. It's a total disaster. The spec is full of typos too. This is not a hackish attempt of some inexperienced computer science graduate student, it is a language developed by one of the richest corporations on earth.

Regarding the fact that Dart has Null pointers, someone on Reddit commented "what were they smoking".

Someone commented on HN that Google does not hire programming language theory experts. I wish I could vote that up a hundred times.

A few extra instructions protecting the bignum's use do not have a significant cost.

In http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... Tim Sweeney says:

  Factoid: C# exposes more than 10 integer-like data types,
  none of which are those defined by (Pythagoras, 500BC).

  In the future, can we get integers right

  Neat Trick:
  In a machine word (size 2^n), encode an integer ±2^(n-1)
  or a pointer to a variable-precision integer
  § Thus “small” integers carry no storage cost
  § Additional access cost is ~5 CPU instructions
  But:
  § A natural number bounded so as to index into an active array is
  guaranteed to fit within the machine word size (the array is the
  proof of this!) and thus requires no special encoding.
  § Since ~80% of integers can dependently-typed to access
  into an array, the amortized cost is ~1 CPU instruction
  per integer operation.

  This could be a viable tradeoff.

In Dart this becomes more constrained as it uses dynamic typing. Apparently the types specified by the programmer will be thrown away when it is compiled down to VM instructions. They are only used to specify/check interfaces.

What this means is that those tags become quite large in the implementation. You can try any Common Lisp or Scheme R6RS without type inference to see how fast or slow this is in practice.

I don't completely understand the second trick. Where are the bignums?

The Go guys seem to have gone the opposite route, designing the C successor they themselves most want. That's far more likely to please others in the long run.

[†] Edit: someone misunderstood me here. I'm not advocating this supercilious attitude, I'm saying it's a mistake that leads to worse languages.

As a full-time GUI developer (Java/SWT) this is so true it hurts. I would love to see the actor model and/or functional reactive programming become main-stream in this space. The observer pattern alone is insufficient...

I made a language for teaching programming to kids that uses CSP as a basis for the GUI where each event is a channel, so I'm quite interested in any literature in this area.

First, the actor model need not imply a separate thread/process for each actor. It's quite possible and in fact common (in Scala's built-in actor library and various Java actor libraries) to run a very large 100k pool of actors in a pool of well under 100 threads. [1] So, the typical notion of having a single UI thread can mesh quite well with actors (just have the UI event loop pump each actor's event loop during idle).

Second, since actors process messages - which are conceptually the same as events - an actor has messages pushed to it by widget(s) upon user interaction. (If this sounds identical to the observer pattern, it's because it is). There's nothing interesting about this step other than the "an event is a message" concept.

Third, and this is the really neat part, actors often involve some concept of blocking on a receive() call - which is an inversion of control from the observer pattern. That is to say an observer/listener is invoked by the UI framework when an event occurs, but an actor, which conceptually has its own message/event loop, can consume events at will. Thus the inversion of control.

So your classic listener looks like this:

  // Added via $("#foo").click() or some such...
  function onClick(e) {
    // do something ... any state must be stored external to this callback
  }

  // The event loop is started up and pumps indefinitely...
  function loop() {
    // any state is local
    while (running) {
      switch (receive()) {
        case ....
      }
    }
  }

I posted [2] a while back and there was a decent discussion at http://news.ycombinator.com/item?id=2972581. The section 5 of [2] really describe the idea neatly.

Hope that helps. Please let me know where I left things fuzzy.

1. Actors That Unify Threads and Events - http://lamp.epfl.ch/~phaller/doc/haller07coord.pdf

2. Deprecating The Observer Pattern - http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.p...

A saner way is to implement an event bus and send update events to it letting the main thread update itself from the bus. Some frameworks do use this model but really, it would be much nicer if the language itself could do this.

I view dart as javascript grown up. It's not that much different from java et al, but it's different enough.

Only time will tell if it will replace javascript, but I'll be doing my bit to help.

I was a little bit annoyed by the braces/semicolons on first glance but spent a few hours today reading the documentation and language reference etc.

It does seem like Dart is a "grown up" language, as you say. It's so packed full of goodies that it seems preferable to JavaScript in every way, except for the fact that JS is already here and has a large user base.

People who've invested a lot of time in learning how to make JS work might have a preference for sticking with what they know, but I think the general reaction today has been to place too much onus on the Dart team to say why it's better than JS.

It would be interesting to hear opinions from John Resig or Douglas Crockford. I'm hoping they're giving the matter some thought before weighing in on this, rather than just indifferent.

Something smells, here.

Anyone who's used GAE has been badly burned, if not deceived by Google. Many unpopular, or costly API's were revoked unceremoniously. It is not easy to understand Google's intentions because they never seem entirely genuine or devoted to anything. This fly by night attitude is not acceptable for a tools developer. Developers want to trust people that are dedicated to their work. And I just never get this attitude from Google.

I've seen many really good reasons for thinking that the web programming community hoped for something lighter and more innovative from Google.

There are many good reasons why most of us avoid web-programming in Java and C#, especially those of us in smaller shops where one person might have to tackle the full stack.