Google introduces Dart, a new programming language for web applications | Hacker News Reader

Google introduces Dart, a new programming language for web applications

googlecode.blogspot.com

127 pointsandysinclair67 comments

While Google may need this for building large applications, this is something that the web could do without.

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

I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web.

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?

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 agree with most of what you're saying, but I think an indirect counter-example is C. It's not technically a universal intermediate language, but it's widely considered to be a "portable assembly language"; which many vastly more dynamic languages compile down to. I think the web could use it's own version of something like C -- that is, a low level, no-frills language that maps closer to how hardware works.

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)

You're assuming that all code found on the web is well-written, without bugs and with no malicious intents. Both Java and CLR bytecodes are designed specifically in a way so that they are verifiable, so that the compiler can be sure that the code doesn't do anything it's not supposed to do (e.g. access IO functions, write to unallocated memory, spawn new threads, ...). Also, a browser has to be able to ensure that untrusted code can only use a limited amount of resources, that is why we have garbage collection, and VMs (interpreted/JIT compiled code can be controlled and interrupted more easily than native code).

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

I am assuming no such thing, that's why I suggested pointers and such should be left out. I'm not actually literally suggesting that we put C in a browser, I'm using it as a design metaphor. You can do fast and low level without C style pointers (for example, fortran* .. not that I'm advocating fortran either )

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.

How about using ordinary machine code and making the browser behave like VMWare? Such an approach would be good for both speed and safety, no? Yeah, that would require webapp authors to make separate binaries for different architectures, but if they're writing some monstrosity like a web version of Photoshop, they want that level of control anyway! Meanwhile the rest of us can keep on using HTML and hop off the standards treadmill.

Yes. And since Javascript is so popular, we should base the name of this IL on it- I suggest Java.

I'd rather avoid Carpal Tunnel Syndrome, thanks.

I'd suggest not typing out IL by hand then.

> The web needs a standard Intermediate Language: a machine code.

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.

The point is not that they are already all over this but rather that an IL is something that all the browser makers could get behind.

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

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

> The point is ... that an IL is something that all the browser makers could get behind.

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

If they built an IL that can also be implemented in Javascript they might have a chance.

e.g:

  Javascript → IL → Javascript

Yes, that's what I said!

Sorry, I must have missed the word 'in'.

The web needs a standard API for displaying content. 95% of the client-side headaches out there are due to browser DOM rendering and event model quirks and incompatibilities.

Web != API

While looking through the sample code I found this gem:

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

Funny enough in javascript 1234567890123456789 % 2 == 0.

No IDE support, no VM in Chrome yet, also no support for calling existing javascript libraries. These three things guarantee no quick adoption. I have no idea what Google is thinking.

It's a very early tech preview.

Wouldn't "adoption" include the things you listed?

There is apparently some support for Eclipse[1], but I have not been able to find more details.

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

Perhaps just not have them ready yet? Who said Google wants "quick adoption"? The SPECIFICALLY state on the language page that its design is in flux and they ask for user input to improve it.

I can't open the website on my iPhone. I hope that's not a karmic hint on the interoperability of the language.

More discussion: http://news.ycombinator.com/item?id=3092558 (it happens to be the top link also)

Is the JavaScript that comes out of the Dart compiler/transpiler readable (like the JS CoffeScript generates) or is it mush like GWT?

That depends on how close is Dart to Javascript.

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

Did I miss the part where it says this will be an open standard? This looks like embrace and extended but I hope I am wrong.

You're not wrong, sadly. See http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAK... for a discovery document from a recent court case that indicates what Google's approach to things like this is nowadays.

The language spec is open. "We've made the language and preliminary tools available as open source on dartlang.org"

I was expecting something more innovative.

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.

That page crashed MobileSafari on iPad and continues to after a reboot. Is it just me?

Crashing Safari on OS X, too. Or rather, the tab hangs.

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.

Safari 5.1 on Snow Leopard. No crashes. Works without any issues.

It appears they fixed it... sort of. The box with the highlighted code is no longer on the page, and now it works in Safari.

What box of highlighted code? The samples box with the run button?

I suppose, if you see it. I just looked in Firefox, Chrome, Chromium, Safari and Opera and while there was such a box originally, I do not currently see it on the page.

Surprisingly, it works perfectly on a Symbian^3 device (Nokia C7-00).

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

It's sending me back to Hacker News after it completely loads on my Blackberry.

Just go to Dartlang.org it's crashing in safari.

Safari 5.1 on Snow Leopard, no crashes here.

Given that it is from Google, perhaps it is a feature, no?

Same here. When it doesn't crash it freezes.

The optionally static types in the Dart language seems like a good idea. You get both beautiful, simple code, like in Ruby, and the possibility to speed up execution by adding types later.

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.

Full type inference also lets you write beautiful, simple code -- without even needing to add types later, you get them now. And speeding up execution is just a bonus, the main benefit is catching errors early, and refactoring safely.

You cannot add "full-type inference" on top of a language with a dynamic type system. You also cannot add such type inference to an object-oriented language, like Scala (it may be possible, but very hard and nobody did it).

     the main benefit is catching errors early

Dynamic typing isn't about not specifying types. Dynamic typing is about creating types at runtime.

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.

There's an real conflict between static typing and eval() or reflection.

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

Doh, too late to edit.

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

Unfortunately, there is no type inference system (that I know of) that can handle types that programmers use in dynamically typed languages on a daily basis. For example, consider the Django admin property 'list_filter' [1] or the Clojure metaprogramming functions 'proxy' [2] and 'defrecord' [3].

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

list_filter seems to be a closed sum type -- why do you think it's not simple to encode or infer as a static type?

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.

Actually, I didn't mean to type the whole function, but only the parameters... One would require something like union types, e.g. list_filter has type

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

Now, this type is certainly encodable in a modern advanced type system (although most statically typed languages utilize type erasure for compilation, so you would need tagged unions (Algebraic Data Types) for this), but I cannot imagine that any language is capable of inferring such a type. Maybe OCaml, but again, we would need polymorphic variants for that.

Instead of (a < SimpleListFilter) you can use a type-class constraint and an existential, or an explicit record of methods. In Haskell, anything you use will basically be inferred, and Haskell can encode that, though you would have to choose different primitives to encode that relationship than subtypes.

To a point, JavaScript already has type inference: https://mail.mozilla.org/pipermail/es-discuss/2011-September...

One of the design goals: "Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution."

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 a lot of server side programming for which Go probably wouldn't be the ideal language. Room for more than 2 languages in the world I think :)

Like what? Go is an absolutely excellent language for server-side programming. I've yet to find anything it wasn't suited for.

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.

What do you mean by "server side programming"? That's a pretty wide net to cast. Do you really think that Go is the ideal language for every bit of code that doesn't happen to run on a client of some sort?

Server side != systems programming.

Think server side web programming.

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

This is a great idea. With optional typing + V8 this could be really fast. Google can leverage its strengths while opening up a language that lots of people already know to additional server side use.

Unless all major browsers support it, the adoption will be painful and slow.

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

From the article:

"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?

not much ;)

Afaik they only abandoned Gears, not GWT.

And it's not like they abandoned Gears because no one was using it, but instead because Gears was so successful that many of the features got (sort of) rolled into HTML 5.

yes finally an alternative to javascript! zomg so excited :3

Reply on news.ycombinator.com