
Dart language - haasted
http://www.dartlang.org/
======
thristian
Mozilla's Brendan Eich, inventor of JavaScript, on the Dart memo leaked a few
weeks ago:

 _A Dart to JS compiler will never be "decent" compared to having the Dart VM
in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and
Mozilla, but the first two are enough) will never embed the Dart VM. So "Works
best in Chrome" and even "Works only in Chrome" are new norms promulgated
intentionally by Google. We see more of this fragmentation every day. As a
user of Chrome and Firefox (and Safari), I find it painful to experience,
never mind the political bad taste_

From here: <https://news.ycombinator.com/item?id=2982949>

~~~
georgemcbay
I disagree with his premise.

The Dart to JS compiler doesn't have to be "decent" compared to having the
Dart VM in the browser to be useful in a world where other browsers don't use
the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript
performing the same task in another browser.

If direct Dart code runs faster than JavaScript on Chrome, that's a nice
bonus, but if it runs as well as similar code that was originally written in
JavaScript on the other browsers (when the Dart code is compiled to JS) that's
good enough. Dart on the other browsers isn't competing with Dart on Chrome,
it is competing with JavaScript on the other browsers and that's how it should
be measured.

And if it turns out apps in Dart on Chrome really blow away apps in JavaScript
on other browsers to the point where both devs and users start embracing
Chrome even more for these gains then hopefully that will light a fire under
everyone else to either adopt Dart or do something to fix what would then be
an undeniable problem of JavaScript.

~~~
thristian
I think you have missed the context of his remarks; perhaps I should have
pasted more from the original post. You seem to be talking about "what is
necessary for Dart to be a viable Web content language", while (I believe)
Brendan is talking about "what are the consequences if Dart becomes a viable
Web content language".

If the Dart → JS compiler produces "good enough" results, and web authors wind
up adopting it en masse, then suddenly a chunk of the web "works best in
Google Chrome", and every other browser manufacturer is put into a very, very
awkward position. They can do nothing, in which case their continued relevance
depends on Google continuing to ship the Dart → JS compiler (and diminishes as
users switch to Chrome). They can license the Dart VM from Google, in which
case their continued relevance depends on Google continuing to license the VM
and we have another large chunk of the Web based on a single binary
monoculture (which worked so well for Flash!). Or, they can try to develop
their own Dart VM, in which case they'll be eternally chasing the tail-lights
of Google's VM, kept behind by Google's head-start and Google's engineering
power. None of those options is very pleasant, in the long run, for anybody
who doesn't own Google stock.

As Brendan's original comment points out, this choice is not unique to Dart.
Currently browser makers have picked option 3 ("write our own") to deal with
V8, option 2 ("licence Google's implementation") to deal with WebM, and so far
option 1 ("ignore it") to deal with SPDY.

Under the carefully-managed tension of ECMA, the ECMAScript standard has
become a much more practical language to develop in directly, and to target
from higher-level languages — and with the agreement of all the major browser
vendors including Google. It's not immediately obvious that a project like
Dart is even needed; even if it is a major technical advance, it's a political
regression.

~~~
georgemcbay
I understand the context and still disagree. If Dart is so much better than
JavaScript on Chrome and if its Dart->JS engine does a good enough job of
creating usable JS on other browsers that developers are willing to commit to
using it to write apps then, well, that's too bad for everyone else, isn't it?

Why should Google put the brakes on improving client side development just
because it puts other browsers in the uncomfortable position of having to
license Dart (for free, since it is OSS and has a liberal patent grant)?

The same would be true if Microsoft created some sort of .NET->JS compiler
with their own VM for IE, or if Mozilla did the same with some new language.
As long as they bridge to JavaScript, more power to them. Client side web
development could certainly use some of the tools that these different
language environments could offer and if it kicks off another performance race
to get browser-side languages even faster (especially on mobile devices), so
much the better for everyone.

I really don't see how there is any downside (to anyone but maybe Brendan
Eich) to widespread usage of Dart unless the Dart->JS code proves to be
suboptimal, but in that case devs won't use it.

~~~
thristian
When I first got onto the Internet, nearly every page I came across had a
little image at the bottom saying "Best Viewed in Netscape Navigator". Since I
was using Netscape, everything worked fine and I didn't care. Some time later,
I began to see images saying "Best viewed in Internet Explorer". Everything
still worked fine, so I still didn't care... but as time went on, more of
those images popped up, and the pages they appeared on began to look much,
much scrappier in Netscape than they did in Explorer. While most of them still
worked, more or less, Explorer made a noticeable improvement.

So, three cheers to Explorer for defeating Netscape and improving client-side
development for everybody, right? Find a web-developer who still has to work
with IE6 and ask them what they think.

Right now, Dart is freely-licensed and available to everybody, but who can
contribute to it? Who will be allowed to veto compatibility-breaking changes?
What happens if Apple announces some new hardware platform, and then Google
coincidentally decides that supporting that platform in the Dart VM is no
longer a priority, refuses to accept patches for it, and later refactorings
happen to make it very difficult to maintain outside the official tree? What
if the Dart VM becomes strategically important like Android, and current
releases are only available to approved partners?

Sure, it's very unlikely that all those things would happen, and fairly
unlikely that even one of them would: up until now, Google has stuck pretty
close to the "do no evil" thing. But if we stick with openly, collaboratively
created technologies, those things are _impossible_ , and "impossible" is
better than "unlikely" in my book.

If Dart were some kind of server-side thing Google wanted to use to increase
the responsiveness of their sites, or something else internal to their
systems, I wouldn't care — they're allowed to do whatever they want in the
privacy of their own servers. It's only because the value proposition of Dart
is "give Google an inherent advantage of control over the Web, and in exchange
you will get shiny things" that I'm concerned. There'll always be more shiny
things, but (so far) there's only one Web.

~~~
WayneDB
"So, three cheers to Explorer for defeating Netscape and improving client-side
development for everybody, right"

Abso-friggin-lutely! You should be thanking Microsoft and Internet Explorer
for upping everyone's game. They're the ones who introduced XmlHttpRequest.
You knoww, "ajax"?

It's their browser and they can do what they want with it. If you don't like
it, don't use it. If everyone else likes it though, tough luck for you. Go
build your own browser and language and drum up your own support for it. All
of this political correctness is a bunch of bull.

~~~
BrendanEich
Must some historical fact or pattern of facts be "all good" or "all bad"? Grow
up!

Microsoft added XHR to IE when they gave Java the boot in a spat with Sun, in
order to keep Outlook Web Express in working order in IE. Was that "all good"?
Clearly not for Sun or Java!

The browser wars phase I had no winners. Yes, IE's DHTML innovations such as
innerHTML were a win, and Netscape should have agreed to implement and
standardize them. No, the long IE6 stagnation and legacy were Not Good.

~~~
WayneDB
Wow, really? Grow up? Nobody said it was all good for everyone. I made a
counter-point that was clearly as balanced as the original point.

Anyway, it really depends on your point of view. Personally I love the IE6
stagnation and other failures that affect the web such as the epic lameness of
Javascript. Why? I think the whole platform sucks and I'm glad to see it fail
and push people to build better solutions.

~~~
BrendanEich
"Abso-friggen-lutely" on top of "three cheers" lacks qualification about the
thing you cheered being less than good for anyone. You were abso-friggen-
lutist.

Anyway, the open web standards are not failing. Dart is not a clearly better
solution. I get your point about XHR, but do try to take mine about the whole
history being a mixed bag, including what IE did. We can do better.

~~~
WayneDB
georgemcbay basically said [why shouldn't Google do what they want with their
browser?], to which thristian replies [because...Microsoft]. I think that's a
bullshit argument, especially since there's nothing about Dart that threatens
to take away anyone's freedom to continue using Javascript or whatever else
comes along.

I gave a bullshit reply to make a point; let's call it hyperbole. Of course I
know that it was a mixed bag for everyone. Some good things did come out of it
though, IE6 is almost gone and those good things are still here (and they've
evolved). Evolution is slow and life itself IS indeed a mixed bag. Business is
WAR!!

Anyway, I love, love, LOVE the fact that people are working on giving us lowly
blub programmers a choice. :)

EDIT: Didn't realize who I was talking to, so let me be really clear that I
have a LOVE/HATE relationship with all things in tech, including Javascript!

~~~
BrendanEich
I have mixed feelings about JS and most software, but moreso JS than, e.g.,
Unix (BSD kernel code in the late '80s, not to date myself too much).

People seem to think I have some big ego investment in JS, but it's this thing
I did in a hurry, but with a purpose that caught on when the web was young and
growing fast. JS is not done, yet it will be hard to replace.

JS is easier to extend than some here claim (and as my recent comments have
noted, not all the parties on the record asserting that it's hard to "fix" are
truly giving it their best effort). As with most web standards, you can't
remove stuff predictably, but new and more winning extensions can help retire
worse old forms.

Business may be WAR but the modern browser era is marked by claims of peace
and openness and standards conformance. So while Dart, and (I joke; I hope
this doesn't happen) matching novelties from Apple ("Flechette") and Microsoft
("Javelin"), will take some attention off the standards, the forces operating
in favor of standards will probably manage to keep JS evolving.

I actually miss some of the Googlers who have worked in TC39, or around the
edges, but who are now full time on Dart or other projects. It seems like a
lost opportunity to me, but it's Google's call.

------
cletus
I don't speak for the team but I believe I can add some perspective.

Think of it this way: what is GWT? GWT os compiling Java, a statically typed
language, into Javascript. If you've used GWT you'll know that particularly
early on there was a lot of friction. What's simple in Javascript with
anonymous objects and duck typing doesn't quite gel with Java so you've had to
do things like use JSNI for edge cases.

Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail
isn't written in GWT, GWT is aimed at that kind of application with deferred
binding and the benefits of static type analysis.

What if you took that expertise (of GWT and static type analysis in producing
Javascript) to produce a language that could run on the server, run in the
browser (for browsers that support that) and compile to Javascript (for
browsers that don't)?

The last point is particular is key to driving adoption as no one is going to
develop only for Chrome.

I see it as no surprise the syntax is Java-like. I fully expect sometime soon
to see a JVM implementation that will then leverage all the existing Java
libraries.

In that context (IMHO) it makes a lot more sense. It might not be solving the
problems you're interested in but it is definitely solving a particular set of
problems.

~~~
chintan
IMHO, this is not a "break away" approach as originally indicated in the
leaked memo.

One of the biggest pain point in web dev is the inconsistent DOM
implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI
controls. And something about the "Web", Semantic Web/URIs or a new approach
to programming on Web. This is _NOT_ a break away language in any sense - its
more re-packaging.

~~~
cletus
I'll stress that it's early days for Dart. Go was announced in 2007 and only
this year is going to a version 1.0.

I don't know what the timeline is for Dart but I will say this:

1\. If anyone is capable of the long sort of time frame that something like
this can benefit from--event _requires_ \--it's Google;

2\. If there is anyone who's qualified as a domain expert in Javascript
generation it is, by virtue of GWT, Google; and

3\. If there is anyone who's qualified to speak to the limits of what you can
do with Javascript it is, by virtue of Chrome and V8, Google.

If anything, I believe the error here (if you can call it that) is failing to
properly set expectations and communicate the goals of the language (as
witnessed by all the comments on this thread from people who were expecting
something more and/or different).

~~~
edsrzf
Small correction: Go was announced in November 2009.

~~~
dasil003
Thank god. I was starting to think I'm getting old if 4 years goes by that
quick.

------
sambeau
This is _completely_ the wrong thing to do.

Google should be proposing a standard, open, byte-code compatible,
Intermediate Language standard that can run Javascript and in the interim run
_on_ Javascript.

That is something I could see Mozilla and Apple getting behind.

Only once they have actively campaigned for this should they be adding new
languages to the browser which fracture the web.

I had hoped that Dart would surprise us and turn out to be a 'machine-code for
the web' implementation. This would have been a much smarter move, I believe.

~~~
leoc
> Google should be proposing a standard, open, byte-code compatible,
> Intermediate Language standard that can run Javascript and in the interim
> run on Javascript.

> That is something I could see Mozilla and Apple getting behind.

Why would you expect either Mozilla or Apple to get behind such a proposal?
Apple has a powerful self-interest in making sure the Web remains a second-
best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the
premier app platform - but it's no bloody good to Mozilla if the web is the
world's #1 web platform but Mozilla has no control over it anymore. The _last_
thing Mozilla wants to see is the Web browser become some fairly-easily-
implemented, highly-interchangeable runtime platform adhering to a stable,
open spec somewhere. This would, I think, be very good for the world at large,
but it would undoubtedly be very bad for Mozilla - it's what is known as the
_commoditization of the platform_. Mozilla's self-interest is served by
keeping as much of the Web as possible controlled, in the minutest detail
possible, by the hard-to-join club of major browser vendors. Right down to
things like the lexical syntax of JavaScript. So in reality, as soon as Google
proposed such an IL, Mozilla's advocates would start blowing smoke about "oh
no, another Java".

~~~
JimBlandy
At a technical level, virtual machines are not the panacea many folks seem to
think.

Certainly, VM byte code languages are often simpler than silicon processors'
machine languages; perhaps they offer safety guarantees; and perhaps they
provide garbage collection. These are all big wins for language implementers
targeting such VMs.

But what no virtual machine will ever do is make modules written in different
source languages work together transparently. Any time one module calls
another module written in a different language, at least one side of that
boundary needs to be written with a detailed understanding of _both_
languages' semantics.

Tiny details of the semantics influence the idioms people settle on in that
language --- and interfaces are designed around those idioms. For example,
JavaScript conditionals treat the empty array and the empty object as true,
while Python conditionals treat them as false. Each of these facts shapes what
people expect of a "natural" API in that language --- and that ensures that
modules written in other languages will always "speak with an accent", or seem
unnatural, at best.

You can define a common data world, as the .NET CLR does, and extend each
source language to cover that world, but the effect is to change each
participant language into a gloss on the common data world. This is why
CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and
CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate
from JavaScript's types and objects.

Each programming language is like a city occupying an island: commerce within
the city is much less expensive than commerce between islands. Although it's
sometimes worth it, dealing with "foreigners" is confusing and risky. No VM
will change that.

~~~
justncase80
It seems to allow for more variation in languages. The only time you really
need to worry about those other languages is when you're trying to load
modules written in other languages. At least that's how it works in .net. You
can have pretty significant semantics from language to language and as long as
you don't care about other languages actually loading your modules then it
doesn't matter. If you concede that the problems of the lang->il developer are
essentially the same as the lang->lang developer, then shouldn't we evaluate
the il option strictly on it's merits? Such as reduced compilation at runtime
and smaller payloads over the wire? As well as, optimally, less quirks than a
language like JS. Not to mention existing lang->il compilers would have much
less effort to retarget their output to the new platform. It just seems like a
huge win to add the vm layer as the base instead of a general purpose language
in every way.

~~~
JimBlandy
Oh, targeting a good VM is a huge win over a typical machine language for an
implementer. My prediction is specifically that the inter-language paradise
some expect will never come.

But even within the points you bring up, I'm not sure that VMs are as winning
as they're made out to be. Size and compilation time aren't somehow
intrinsically better for VMs; JS does quite well on both fronts these days.
And I'm not convinced JS's quirks are harder for implementers to cope with
than a silicon machine language's.

------
nene
My hopes were high, but the more read about it, the more it started to look
like Java:

    
    
        class Foo implements Comparable Observable Deniable ...
    

Why not have interfaces like in Go, where you just define a set of methods and
all classes having the methods will automatically implement the interface.

    
    
        Collection<E>
        HashMap<K,V>
        HashSet<E>
        LinkedHashMap<K,V>
        List<E>
        Map<K,V>
        Set<E>
    

Why not just Array and Hash? And what's up with the whole generics thing -
that's just plain old Java.

    
    
        int
        bool
        String
        Object
    

Why do some types start with lowercase and some with uppercase letter. Why not
use a sensible naming convention?

    
    
        square(n) => n + n;
        square(5); // returns 25
        square2(n) { n + n; }
        square2(5); // returns null
    

Why not have an implicit return value everywhere?

I could go just on and on...

~~~
jurre
_> int bool String Object Why do some types start with lowercase and some with
uppercase letter. Why not use a sensible naming convention?_

Primitives and objects, it kind of makes sense but I do see your point.

~~~
nene
But the thing is, they are not primitives:

> _Although you might expect int and double to be primitive types, they're
> actually interfaces that extend the num interface. This means that int and
> double variables are also nums._

~~~
nathanwdavis
That's actually kind of like Haskell.

------
timclark
Aaaarghhh! It is full of semicolons.

Is it really necessary in the 21st century to create a language that
terminates lines with semicolons? I am sure I have seen some other languages
in the past that get by just fine without them.

~~~
munificent
The language isn't done yet. Now is the time to let us know if you want
semicolons to go away. I know some of us on the team do too, but public
interest will help a lot.

~~~
danmaz74
I'll give you my votes then:

\- no braces where avoidable, no semicolons where avoidable

\- release early a free, open source reference development environment that
really helps in developing with Dart. The biggest pain with Javascript, imho,
is in the lack of development tools really thought out for it, and not just an
adaptation of Java/C/whatever other editors

    
    
      - if you develop said IDE as a web-IDE, even better (why not writte in dart itself?)
    
      - give as many inobtrusive visual cues as possible to easily see tab alignment, syntax coloring, etc.
    
      - integrate unit testing facilities in the IDE

~~~
munificent
I like everything you propose here. Dart is earlier in development than I
think most people realize, and I really hope we can get to something like what
you're listing. Definitely self-hosting and a self-hosted IDE would be on my
love-to-have list. As a testing nerd, integrating testing would definitely be
on it too.

~~~
danmaz74
A good development environment is something where you could really
differentiate yourselves, and I guess you could very easily integrate
introspection and analysis features into chrome to help with it.

I've been thinking for years that if I ever were to develop a new language, I
would start from developer usability first - I think there is much more to
innovate there than in the core language features, nowadays. Developer
usability is tightly coupled with the development tools the developer can use,
not just with abstract language features. And especially for web development,
you can't think only about top of class developers.

As I'm at it, I'll write here my dream feature of any language and IDE - not
knowing if it is really feasible, but it doesn't look really impossible to me.
Use case:

\- You run your unit tests

\- An assertion fails/there is an error

\- A debugger brings you to where the problem is

\- You can _step back_ from where you are, make changes on the fly to your
code and the tests, and _step forward_ to the assertion/error again.

I guess that with a VM, and excluding some operations that depend from
external status and which are destructive, this could be possible, and it
could allow an incredible speedup in development...

~~~
drothlis
Certainly feasible: Smalltalk debuggers do this. And Smalltalkers (allegedly)
use a workflow just like you describe.

~~~
cwp
Yup. I often do something like this:

    
    
      - write a test for a method that isn't there yet
      - run it, get a red bar, as expected
      - run it in debug mode, and get a debugger
      - write the method implementation in the debugger
      - possibly write other methods that the new method calls, also in the debugger
      - resume the program, get a green bar
    

Writing code in the debugger is great, because you've got all the runtime
state right in front of you, and you can step through the code you're working
on. I'd love, love, love to see this in Dart.

~~~
danmaz74
But, is it possible to step backwards from the current state of the VM, to
execute a changed code?

------
shykes
I am most excited about the concurrency model!

"Concurrency is supported via actor-like entities called isolates. An isolate
is a unit of concurrency. It has its own memory and its own thread of control.
Isolates communicate by message passing (10.14.4). No state is ever shared
between isolates. Isolates are created by spawning (10.11)"

<http://www.dartlang.org/docs/spec/dartLangSpec.pdf>

I wonder how they compile this down to Javascript?

~~~
psawaya
That doesn't sound so different from WebWorkers, which you can already use
from javascript in newer browsers.
<https://developer.mozilla.org/en/Using_web_workers>

~~~
shykes
The model seems slightly different - don't WebWorkers share state?

~~~
dasmoth
No, just message passing (notionally via JSON).

------
akavlie
If you're going to go to the trouble of creating a JavaScript replacement,
making something more like Java is the wrong way to go IMO. CoffeeScript is a
lot more palatable.

~~~
jamesrom
CoffeeScript basically simplifies (and does a pretty good job, imo) existing
JavaScript language features. Whereas, Dart adds classes and interfaces and a
few other neat things.

Admittedly, however, I do cringe whenever I see things like x.compareTo(y) or
X x = new X();

~~~
bgarbiak
Classes, types, better syntax - it's all available in JavaScript today, in
it's various 'forms' (CoffeeScript, Mootools, Closure, etc.). Dart isn't a bad
language, it just doesn't bring anything exciting to the table (or I fail to
see it). Seems like it's ECMAScript 5 but early-bound and with Java syntax.
And it runs only on browsers that already support ES5 - this one is really
underwhelming.

------
paulkoer
The one thing I don't understand is why people work on new languages for the
browser instead of giving us a platform (virtual machine / intermediate
representation, whatever) to implement languages against.

I mean here in this thread we are already seeing it. Some people like
semicolons, some people don't. Some people like a prototype based object
system, some people like a class based system. And on and on.

I think what would really benefit us is a platform (like a JVM for the browser
with a great API replacing the dom) where people could implement languages
against. we would get

1) A lot of competition of languages (see what is happening on the JVM right
now... Clojure, Scala, Groovy ... you name it), hopefully giving us better
languages. Javascript has its strenghts but could you imagine that in such an
environment a language that doesn't allow you to test whether or not something
is a string would make it very long?

2) People could make their choice and be happy. Then you can program the
server and the client in the same language, which is pretty much the main
argument for server-side javascript.

Let the languages compete instead of giving us one and now another language
for the platform!

~~~
ErikCorry
I think the Dart VM will be a nice target for compilation from other
languages. In general it's easier to put a typed language on an untyped
runtime than it is to put an untyped language on a typed runtime.

Before Google I worked on an academic project that built a small Smalltalk-
like VM that was also a compilation target for something that was very close
to unthreaded Java. Worked pretty well.

~~~
paulkoer
> I think the Dart VM will be a nice target for compilation from other
> languages.

This would indeed be nice but it seems that google wants to push the language
more than the VM. I quite get this because saying "you can now run your
favorite language for the browser" seems much much more attractive than saying
"look we made programming language 1001 and this is what you people should be
using now!".

> In general it's easier to put a typed language on an untyped runtime than it
> is to put an untyped language on a typed runtime.

I have no knowledge of how one would do this but a lot of dynamically typed
languages exist for the (I am assuming) statically typed platforms such as the
JVM and CLR now.

~~~
ajanuary
They do, but it's a heck of a lot of work. The CLR has the DLR (Dynamic
Language Runtime) that does a lot of the work for you now, but it's still a
pain.

------
jashkenas
A question to ask yourself: If this had been Microsoft creating an IE10-only
language to replace JavaScript, instead of Google, would you feel any
differently about Dart?

~~~
cwp
Definitely.

But if they released an open-source version of IE, started shipping IE
frequently for Windows, Macintosh and Linux and released the Dart language
spec and implementation under an open-source license... well, then I'd like it
a lot better.

------
cromwellian
Probably the biggest difference between JS and whatever revision to it you
like, and Dart, is that dart is early-bound. That means, you can't change the
list of methods or fields present on an object at runtime.

It doesn't really make sense to ask "Why should I switch from a language I
already love?" If you're already productive and love what you're using, then
you should probably keep using it.

There are people who want a language that is more modular, scales better than
JS for programming in the large, for IDE tooling, or ahead of time
compilation, etc. Take a look at the Dart spreadsheet Total for example
([https://code.google.com/p/dart/source/browse/branches/bleedi...](https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples#samples%2Ftotal))
I find this code a lot cleaner than JS versions I've seen.

~~~
snorkel
I was liking Dart's syntax but the early static binding is a deal breaker for
me. Javascript would've been stuck in neutral if it didn't support mutable
objects.

------
socratic
Is this effectively GWT 3.0?

The project page is very unclear, so I ended up on Wikipedia instead.
Wikipedia actually has a leaked memo that seems to do a really good job
describing the purpose of the language.

Specifically, the language is meant for three environments: server-side,
compiled to JavaScript client-side, and fast native client-side once there is
browser support. (The main goal is better performance on the client-side,
which is deemed to be very difficult with JavaScript.)

However, the language looks so Java-like, one wonders why they didn't just use
Java and extend GWT with a native Java client in Chrome. Did it just not make
sense to bet the farm on Java when Oracle controls it?

Also, what does the "structured" in "structured web programming" mean?

~~~
cromwellian
Dart doesn't really share much with GWT. The basic language semantics are
dynamic, not static. The types are more or assertions and documentation that
generate runtime warnings, but do not produce compile time errors that refuse
to let the app run at all.

Dart's a lot more like CoffeeScript than Java.

~~~
danmaz74
Only, it looks worse than CoffeeScript from a readability point of view...
just a first impression.

------
frisco
The "hello world" example is incredibly uninformative. What does that have to
do with "structured web programming"? Where is this printed out on a web page?
Does the console output there correspond to the html output? Or some other
console?

~~~
haasted
It's actually runnable if you click the "play"-icon in the top-left of the
code sample.

The "Hello, Dart!" is written to a console emerging from underneath the code
sample.

[https://code.google.com/p/dart/source/browse/branches/bleedi...](https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/hi/hi.dart)
is a more DOM-oriented version of the same program.

~~~
gambo
Hmm strange, I can't see the "play"-icon using FFX 3.6.23

~~~
dchest
Dart currently compiles to JS that runs on Firefox 4+.

[http://www.dartlang.org/docs/technical-
overview/index.html#h...](http://www.dartlang.org/docs/technical-
overview/index.html#howtouse)

------
ohyes
I was hoping for something like the Dylan language.

<http://en.wikipedia.org/wiki/Dylan_programming_language>

It was created in the 1990s and it still looks innovative, even compared to a
lot of the new 'hot commodity' languages like python and ruby. I knew it
wouldn't happen.

If a big corporation like Google put money into something like that, I think
it would dominate the market.

But what they have delivered here isn't even interesting.

(The other option for something I would want would be standardized 'web byte-
code', so that you just re-target a compiler back-end to emit it, and your
language can be used as if it were javascript.

This is neither of those thing and I am sorely disappointed.

~~~
nickik
Yes, man. Dylan ftw. The best language that does not have s-exp syntax. There
are still some guys tring to get a good implmentation out.

Dylan could have been what Objectiv-C is now. It was an awesome project it
just had bad timing.

------
vegai
Creating an object:

    
    
        Greeter greeter = new Greeter()
    

or

    
    
        var greeter = new Greeter()
    

Defining a constant:

    
    
        static final myConst = 1
    
    

Plus there are classes, interfaces... It's just Java?

~~~
munificent
> var greeter = new Greeter()

Well, it's hard to get _that_ much better than that.

> Plus there are classes, interfaces... It's just Java?

Java didn't invent classes. It certainly looks a lot like Java, but it's more
Smalltalk under the hood.

~~~
masklinn
> Well, it's hard to get that much better than that.
    
    
        var greeter = Greeter()
    

there, no need for `new`.

Alternatively,

    
    
        var greeter = Greeter.new()
    

or

    
    
        var greeter = greeter new
    

if it's not acceptable to have arbitrary callable objects.

> it's more Smalltalk under the hood.

The speed and wide-spread use of Smalltalk with the regularity, flexibility
and terseness of Java's syntax? That sounds like a recipe for success.

~~~
munificent
> there, no need for `new`.

Agreed. I didn't say you couldn't get better at all, just not _much_ better.
I'd personally be in favor of ditching new (or conversely making it a method
on the class).

> The speed and wide-spread use of Smalltalk with the regularity, flexibility
> and terseness of Java's syntax?

Oh, you. You may be right. Making a new language is crazy, especially if
you're aiming for widespread adoption. Still, you have to try, right?

Dart is definitely more terse and more flexible than Java. Maybe not perfect,
but it's heading in the right direction. Dart is no DSL-friendly beauty like
Ruby, but I think:

    
    
        var odds = [1, 2, 3, 4, 5].filter((i) => i % 2 == 1);
    

is pretty tolerable without being novel enough to scare people that have never
programmed outside of a curly brace language.

~~~
masklinn
> Agreed. I didn't say you couldn't get better at all, just not much better.

I strongly disagree, it makes away with a keyword and magical syntax, that
_is_ much better.

> Making a new language is crazy, especially if you're aiming for widespread
> adoption.

That's not what I'm saying, I like new languages, and I like interesting new
languages, but it pains me to see you defend (or even work on?) Dart, which so
far looks even worse on the programming-language-progress continuum than Go
does. It barely makes _any_ progress on the very language it's supposed to
replace.

~~~
cromwellian
Well to be fair, the language it is replacing for the most part works, it's
mostly just patching up problems: ability to optimize for startup performance,
ability to program in the large, and ability to write tools easily (IDEs, etc)

Most new programming languages are really just variations on those that came
before them. You've got you're LISP derived, your Forth/Stack derived, your
APL derived, your ML derived, etc.

IMHO, it's hard to consider a programming language in isolation. As far as
'feel' or 'productivity', it really comes down to the ecosystem, the runtime
and tools available. Here I think is where Dart hopes to excel -- make a JS-
like replacement that supports a better runtime and tools story.

~~~
masklinn
> Well to be fair, the language it is replacing for the most part works

They clearly disagree, since instead of taking part of cleanup/improvement
efforts (e.g. Harmony) they decided to build a brand new language from
scratch.

> Here I think is where Dart hopes to excel -- make a JS-like replacement that
> supports a better runtime and tools story.

I fail to see why that would happen, from what I've seen so far there's little
in Dart which is a significant improvement for runtimes. And as far as tooling
goes... well Google's history means they're unlikely to be those handling
that, who's going to build tooling for Dart, and why would they have any
reason to make that investment instead of improving their JS support further,
or adding CoffeeScript support?

~~~
cromwellian
Google's build the Android Development Environment for Eclipse, the Google
Plugin for Eclipse (AppEngine and GWT integration) and Dart already released
an Eclipse environment, and a compiler. So the history seems to be that Google
supports tools.

Google is taking part is JS cleanup efforts, but it's a large company with
20,000+ employees, so it has the reasons to pursue many different paths:
Closure, GWT, Dart, Go, etc.

As for runtime improvement, if the team who has built the one of the
best/fastest JS VMs (V8 team) says the language semantics allow them to do
better, I think we should listen.

The early binding alone allows for substantial improvement. If all classes are
early bound, then you can significantly optimize dead code, you can know
object layouts immediately on load, you can detect effectively non-virtual
methods immediately, and so on. You can pretty much snapshot important
information that you normally have to discover each and every time you load
the application.

------
pyrhho
The thing I was _really_ hoping for from the dart site was an "about" section,
or a "why" section, explaining about the language and their goals, instead of
just jumping to code examples...

~~~
jamesrom
That's a fair point, but it's pretty annoying when you read about some cool
new language but you can't find any good sample code anywhere. anic and
newspeak come to mind.

~~~
ramchip
For the record, anic was and still is pure vaporware. Sample code exists but
there is no working compiler or interpreter to run it...

------
wulfric
Wow guys. Google is not aiming at a next gen Haskell or ML. They are trying to
create a less cluttered Java and a stricter, more performant Javascript. Judge
a solution in context of the problem it is trying to solve. If they got Simon
Peyton Jones to design this it would be somewhat intimidating for your average
webdev[no disrespect].

I'm somewhat disappointed that they insist on a 90's C syntax. It's like
Python/Ruby/Coffeescript never existed.

C'mon Google, you can do way better...

~~~
daviddaviddavid
I think this comment gets to the heart of the matter. People _want_ something
different. They want a Haskell. How many blog posts about Perlis languages
have we seen in the past several months?

Reading these comments I've come across the words: boring, uninspired,
underwhelmed...

I couldn't agree more.

JavaScript's prototypal object model can at least keep my attention.

------
stephenhandley
Pretty disappointed with the lack of risk with this. Conceptually seemed like
something with a ton of potential, but the minute I saw the tutorial
shoehorning the worst of Java and JavaScript into something new, it was a non
starter for me...better being insulated writing CoffeeScript a layer up and
waiting for a compiler.

Things I've noticed so far that I don't like: get/set proliferation,
semicolons, braces, positional args, var for instance vars, int/num dinostyle
pseudo-primitives.

It seems like they tried to do some cool things, but failed in execution. Like
"Greeter.withPrefix(this.prefix);" one-line constructor definition .. where
this.prefix is a "shortcut that assigns the parameter's value to the instance
variable prefix". Eliminate needless code.. but instead of using a dedicated
symbol to call attention to the sugar, they used "this." WTF.. did they
specifically want to kill scanability.

Things I've noticed so far that I like: using "_" as a prefix to enforce
encapsulation.

Enforcing naming conventions as syntax seems at least somewhat python inspired
in the sense of bringing the whitespace is significant design to naming is
significant.. wish there had been more of that.

If someone other than Google were doing this it would be dead in the water
already.

------
perfunctory
Funny to read all these comments just a few minutes after the announcement. I
bet nobody had enough time to explore the language in any significant way. Yet
very strong opinions already.

~~~
clownz0r
On the contrary, I was able to go through all of the tutorials, follow 2
separate live-tweetings, and start looking into the source before the keynote
was over; I'd imagine many here did the same.

------
mckoss
Two things I don't like about Dart, just from reading the tutorial:

1\. Consuctor syntax requires repeating the name of the class when yor define
the constructor. So if you change a class name, you have to carefully find all
your constructors and rename them.

2\. Instance variables in classes seem to be defined at the same level as
class methods. Yet one is an instance attribute, and the other a class
attribute. So you have irregular scoping rules based on type (data vs.
function). This scares me as it indicates functions are "special" and not
first-class types in the language.

------
tcard
A face-washed JavaScript with classes, interfaces and such stuff. I was
expecting something more syntactically close to Go, or at least to Python.

~~~
snprbob86
Meanwhile, I've been slowly eliminating my usage of `class` from all of my
CoffeeScript code. I've found that my code is much more reusable, far less
prone to `this` bugs, easier to reason about, etc. I used to be a huuuge OOP
guy, but now I rarely find a use for classes...

~~~
tcard
Prototypes are fine for a language like JavaScript. They keep things simple.
I'd prefer that CoffeeScript (and Dart, of course) implemented a decent syntax
for prototyping, replacing the JS mess, rather than trying to disguise them as
leaky and half-featured classes.

~~~
jashkenas

        > leaky and half-featured classes.
    

This is a common willful misconception. CoffeeScript classes are isomorphic to
JavaScript prototypes -- the do precisely the same thing. In addition, there
is a shorthand syntax for prototyping objects, if that's more your style:

    
    
        Dog = -> 
          ...
           
        Dog::bark = -> 
          ...
    
        Dog::run = ->
          ...
    

Note that the above will produce the same result as:

    
    
        class Dog
          bark: ->
            ...
          run: ->
            ...

~~~
tcard
I didn't mean that CoffeeScript classes don't cover prototypes —but the other
way around: prototypes can't implement the whole typical class abstraction
(encapsulation, etc.). So I think CoffeeScript would do better implementing a
completely new syntactic abstraction over prototyping that fix all the
JavaScript awkward ambiguities than adapting classes to prototypes. But it's
still OK, I like and use CS classes.

~~~
gryzzly
there are performance reasons for that choice, the prototypal inheritance +
constructors are way faster than anything else at the moment

------
voidr
A language that has type hints class keyword, and interfaces, I really think
Google should have been better off implementing ES.next stuff... This is one
of the most pointless projects Google has ever done, it doesn't solve any web
developer problems, it's just the 999999th language.

They should have just embraced Coffee script.

~~~
jjm
"This is one of the most pointless projects Google has ever done, it doesn't
solve any web developer problems, it's just the 999999th language."

I would say this is a bit too early to take on the 'maximist' attitude, no?

Like munificent said, someone has gota try. At least he put the flag post down
somewhere, and I'm sure he's having fun. Where the maximist point of view
doesn't help at the moment is that most of the time It is projects like this
one where out of the 1000 features, one or two are genuinely super super
awesome new.

Eventually in time, after many projects like this, you end up merging all the
'cool' things you've learned you come up with something super awesome.
Somewhat like learned progress. Already the project has grouped many minds
together, and that has got to be beneficial.

In fact I don't remember the last time anyone has offered up so many voices in
such short time to any language actively being developed nor even in the
infantile stages such as this one.

Btw, from a philosophical point of view, today's 'web developer problem' might
not be tomorrow's 'web developer problem'.

------
rufugee
I'm really surprised to see all the hate here. It's early yet guys...give them
time to hone it a bit.

I'm perfectly willing to live with the Java-like syntax and feel, so long as:

\- I can write in the same language on both the client and server side \-
Solid libraries exist on the server side for interaction with RDBMSes, web
services, etc \- Good tooling support

Those of you complaining about the syntax...do you honestly think regular
javascript is any better? Personally, I loathe javascript's syntax and
inconsistencies...if Dart can solve that and give me good server side
programming support, I'll sign up. That's the problem with things like Node
today...the server side libraries are loosely documented and implemented
IMO...it's very much a Wild West environment.

~~~
pornel
> That's the problem with things like Node today...the server side libraries
> are loosely documented and implemented

Why would different syntax or explicit types change that?

I don't think you have to replace JS to get better server-side libraries, and
better language doesn't automatically give you better libraries and
documentation.

~~~
rufugee
I don't disagree with you. I'm simply saying that's what I'm looking for. Same
language on the server and client...better libraries...better tools. If Google
gets there with Dart, great! If javascript gets there, great! I'm not as hung
up on language syntax, prettiness, etc (though it'd be nice). I'd rather focus
on pragmatism and consistency across tiers.

------
thepumpkin1979
New MIME type "application/dart"... I suspect that Google Chrome will embed a
Dart Runtime when it gets stable, that will be very interesting; I'm not sure
if it's a good or a bad thing though.

~~~
magicalist
OTOH it's not that uncommon these days, especially when these transpiled-to-js
languages want to run without being translated ahead of time (though usually
in production you would want to do that offline)...text/coffeescript,
text/traceur, text/es-harmony, etc etc

~~~
thepumpkin1979
Yeah, but I don't think any of these mime-types represent any threat for
today's Javascript. OTOH Dart(or Dash)'s sponsor already gave us some clues of
that their intentions are. I quote <https://gist.github.com/1208618> "Push for
Dash to become an open standard and be adopted by other browsers. Developers
using Dash tooling will be able to use a cross-compiler to target Javascript
for browsers that do not support Dash natively." again, it says "target
Javascript for browsers that do not support Dash natively [for now]."

------
russellallen
Hmm. A little underwhelmed so far.

~~~
rjd
Yeppp... its like getting a birthday present. You get a moment of excitement
and intrigue. You unwrap it, and .. socks.

You know I'll probably use those socks someday, but its not what I was really
hoping for.

~~~
spaam
best comment ;D

------
seasoup
The only problem I have with this sort of development effort is that it fails
to recognize that Javascript is an awesome language unto itself and has no
need of "fixing" by introducing a completely new language that is completely
different.

Sure, it needs a few refinements here and there, but by and large Javascript
is an incredible, flexible, and battle tested language. As a web developer
with 11 years of experience, who has worked professionally with RoR, Java,
PHP, MySQL, Oracle, and PostgreSQL, my feedback is just stop.

The world doesn't need another tool that obviates the need for engineers to
learn Javascript to program on the web. Seriously, Javascript isn't that
difficult. Just learn it, buckle down and spend a couple months writing
Javascript and you'll be just fine.

If half the time spent writing Dart had been spent learning Javascript
instead, then you would think in prototypes instead of classes, anonymous
functions instead of one off objects, callbacks instead of um... not having
callbacks, and dynamic variables instead of casting, casting, casting.

I'm not claiming Javascript is better then your language of choice, I'm just
saying that as a language, it's awesome. It's not broke, and as a web
developer I'm not looking for something to replace it.

~~~
cromwellian
You don't need to cast in Dart. Dart is not Java. It has concise closures as
well. It has dynamic types.

Javascript has problems. If it didn't, no one would be trying to evolve it and
address it's weaknesses. The language had serious weaknesses, some of which
were addressed recently (TypedArrays, strict mode, etc) and some of which
there is no current fix (consistent, standardized, namespacing and modules),
and some of which cause big performance holes ("with" statement).

Prototype based inheritance is extremely verbose to use. That's one reason why
CoffeeScript is well liked, and why Classes are coming to JS. Prototypes and
eval() also make it hard to develop language analysis tools and IDEs which can
provide correct code assistence, which can refactor large code bases, etc

Javascript isn't broken if you're just writing a few lines of JS in jQuery to
enhance a web page. But it doesn't really scale well if you're got 500klocs of
code and a decent sized distributed team.

~~~
drgath
Sure, jQuery is bad at scale. And by "scale" I'm not talking pageviews, I'm
talking features, development team, etc... For that, modular libraries like
YUI and Dojo are the answer. You can create some of the most advanced web
applications perfectly fine in JS as long as you approach it correctly.

P.S. Don't ever use the term "klocks" unless you want to sound like a
enterprise middle manager who hasn't touched code in 20 years. Just a friendly
tip. :)

~~~
WayneDB
Where are all the great JS tools and IDEs then? You simply cannot compare JS
tooling to what can be had for a popular statically typed, inheritance based
language. It's a whole different league.

P.S. Snide remarks such as that make you sound like a junior programmer who
thinks he knows everything. Just a friendly tip ;)

------
nerdzero
After seeing so many negative comments primarily focusing on the syntax and
verbosity of the language, I felt compelled to create an account to try and
get some understanding of why this is.

The way I understand it, a terse syntax is useful in getting something working
quickly. However, this is not necessarily the best code when it comes to
performance or maintenance. Adding "boilerplate" code not only makes the
compiler/interpreter more efficient, it also makes the job of the maintainer
much easier. Personally, it takes me less time to figure out what a particular
piece of code is doing if the datatypes of variables and return values of
functions are obvious.

Dart seems to understand this well and so makes typing optional which is
useful for prototyping but then also allows you to refactor and explicitly
include types to gain performance and improve maintenance for production code.
Am I missing something? If not this sounds pretty exciting to me.

------
simondlr
Can anyone explain why I should use this instead of other web programming
languages?

~~~
drothlis
From their "technical overview" page <http://www.dartlang.org/docs/technical-
overview/> :

"Dart will include a rich set of execution environments, libraries, and
development tools built to support the language. These tools will enable
productive and dynamic development, including edit-and-continue debugging and
beyond—up to a style where you program an application outline, run it, and
fill in the blanks as you run."

Sounds like a Smalltalk-style debugger running in the browser.

Though it seems these tools aren't actually ready yet: "This is a technology
preview, not a product launch" -- [http://dartinside.com/2011/live-from-dart-
launch/#liveblog-e...](http://dartinside.com/2011/live-from-dart-
launch/#liveblog-entry-102)

------
ericflo
To me this looks a lot like Java but with optional types.

~~~
discreteevent
Why didn't they go a bit further and have type inference? They proved already
with Go that you can have type inference in a language and still have a fairly
light/dynamic feel.

~~~
munificent
Type inference is a tooling feature, not a language feature for Dart. The
tools can do some type inference now, and more may be added later. At the very
least, I personally really hope we get fully inferred local variables.

~~~
equark
You really need to make a list of these types of response on your webpage.

~~~
munificent
Good idea. At some point, we'll probably harvest a bunch of this and put
together a FAQ.

------
jashkenas
If anyone has a good example of what a medium-size Dart script looks like when
compiled into JavaScript -- I for one would love to see it.

------
culebron
I am really disappointed seeing the "yet familiar" argument behind the C-like
syntax.

It takes a day to get used to Python syntax, and another day to make it
subconscious, that is to stop forgetting it.

The arrow in CoffeeScript is a pain to type, but overall CS saves you a lot of
time.

How come Google that can dictate rules to some extent, doesn't have the balls
to fix the long lasting issue with syntax? Why voluntarily subject oneself to,
probably, years of pain?! Did they just start following letter-by-letter the
success stories, like the one of Javascript? (scheme+smalltalk+java/c syntax)

I can't find an explanation to this.

------
radagaisus
I don't understand this. The only thing different here is the async handling.
Why would anyone want to switch?

~~~
Someone
Switch from where?

 _If_ this were as commonly supported (and as performant) as JavaScript, and
if, as I expect, this allows DOM manipulation, I would prefer it over it, if
only for the strong typing.

Also, I haven't read the spec yet, but I would expect the 'VM' to run Dalvik
code. If so, this will make it easier to port your web app to Android.

~~~
minikomi
From the menu example:

    
    
        document.query("#menu").nodes.add(sliderMenu.node);
    

So, yes, DOM manipulation is there albeit kind of ugly.

~~~
munificent
Not perfect, but I prefer that over:

    
    
        document.querySelector('#menu').appendChild(sliderMenu.node);
    

If you have suggestions for improvement, please do pass them along.

~~~
Robin_Message
Bake in a jQuery-like thing, or make it easy to build jQuery-like things,
since I would much rather write something like the following in any language:

    
    
      $('#menu').append(sliderMenu);

~~~
munificent
We had a separate jQuery-like lib that we wrote in Dart for a while before we
figured, "why not just make the main DOM API better"? So this stuff:

    
    
        document.query('#menu').nodes.add(sliderMenu.node);
    

Is a reflection of that. The ".node" part after sliderMenu will go away at
some point. Our DOM lib doesn't currently work like jQuery's "collection-that-
acts-like-an-object" style because we're worried about performance.

Keep in mind that you can always ditch jQuery and go straight to the DOM if
jQuery is too slow. If jQuery was the _only_ way, you'd lose your fast path.

So we've tried to come up with a DOM API that's easier to use, but still
performant. If you've got ideas for how we can improve it, we'd definitely
like to hear them.

~~~
radagaisus
how about literal DOM elements?

    
    
        #menu.add(.sliderMenu)
    

e.g. #,., maybe % or _ before elements, and you have a much more fluent
syntax.

------
rshm
I was expecting dynamically typed Scala, with ready to go IDE from Google and
truck full of apis and tools.

Or a surprise.

~~~
jhck
Re: IDE:

 _09.50: Now they are demoing a full eclipse based IDE for dart, very cool
too, wow_

From <http://dartinside.com/2011/live-from-dart-launch/>

~~~
nailer
> eclipse

Oh. :-(

------
TheMoonMaster
This looks it's just Java flavored Javascript. Why would we use this over
languages that already work such as CoffeeScript, ClojureScript, or even plain
Javascript?

------
ttcbj
I am also disappointed, but in a different way that most commenters. I don't
mind java syntax, and I prefer strongly-typed languages. My concern is that
Dart seems to give up a lot vs. gwt, and not add much.

That is, with gwt you get

\- strongly typed java syntax

\- it abstracts away browser differences, and supports many browsers

\- it lets you run mostly the same code on client and server, and gives you
access to lots of java libraries on the server

With dart, it seems you get a weaker java syntax, and you lose access to all
the existing java libraries on the server. You also seem to get a new
interpreted server side environment. Maybe that will be better/faster than the
JVM, but that is not obvious to me.

Overall, I agree with a commenter above who said that they should have defined
a general VM for web browsers, similar to the JVM, but simpler/faster/more
appropriate. Then, all kinds of languages could be cross compiled into it,
while you could use the language natively on the server.

I think their original memo got many of the problems right - javascript has
become a limiting factor in advancing web development - but I think the
solution lies in a more general VM approach.

~~~
goin
"I think their original memo got many of the problems right - but I think the
solution lies in a more general VM approach".

I think Dart is the preferred way to target that VM. Staying at the language
level eliminates binary format headaches!

Besides, the web should not be binary.

------
harel
Either give me a brand new browser VM with a brand new modern language that is
supported by all browsers or don't bother. If my code will be translated to
Javascript I rather write it in Javascript and control it myself.

I'll happily adopt a new browser language if it offers me benefits that I
don't get from Javascript, but I really don't get the new trend of compile to
Javascript languages.

------
sktrdie
I don't get it. What's the runtime for this? The interpreter seems to be
running on App Engine, so it's probably JVM based, right?

~~~
georgemcbay
Though I saw no direct mention of this in any of the writeups thus far (they
are just announcing it now at GOTO), it appears you can download code for the
the VM, compiler, etc from here:

<https://code.google.com/p/dart/>

(Look in the bleeding_edge branch)

Currently doing a repo pull here so I haven't had much time to look around at
it yet. I'm cautiously optimistic though, it looks quite a bit like I was
hoping Dart would look (a bit of the ECMA4/ActionScript feel on top of
JavaScript).

------
nixarn
I like it. And if they make it work great on the server as well, that's a big
plus. A google supported node.js would be great.

~~~
clownz0r
Even better, a Google supported node.js _with actors_.

~~~
bergie
Hook.io seems to be a reasonably nice actors implementation for Node.js

------
commondream
I'm mainly curious why Google isn't going after some sort of bytecode for
browsers, and then building a language on top of that. That would let
developers use the language that works best for them, and would really open
things up for new languages in the browser.

Does anyone on the Dash team have any feedback on why you guys decided not to
go that route?

------
zeekay
Who wants to begin work on CoffeeScript-for-Dart? Possibly call it Arrow or
Bolt, although I'd find Dash endlessly amusing.

------
SurfScore
I feel like at this point in the development of technology, we should be
moving towards less programming languages (and ultimately less programming),
not more. I haven't spent hours studying Dart, but what does Google hope to
accomplish with this, besides getting their skin in the programming language
game (see Microsoft). It doesn't really do much else that other languages
can't, at least not that I can see. I mean, YOU CONVERT IT TO JAVASCRIPT just
to get it to work! Come on! Programming languages are a lot like web browsers.
There are some that are more suited for certain things than others, but having
so many creates more problems than it solves (especially because they try to
do little, insignificant things differently, just for the sake of being
different).

------
goin
The language could satisfy the trolls at both sides of the semicolons/braces
fence: your favorite editor/IDE could support your style (with two-way tools).

As for the preferred format, I suspect code with ; and {..} may remove some
ambiguity, so it should execute faster. That's the decisive argument in my
book.

Besides being useful by itself, I understand Dart as an intermediate language:
other languages should compile into Dart. Its syntax should be extremely
consistent, so code can be reasoned about.

For one day we'll need 99% accurate machine translation, like from chinese to
english and back, but from Perl to Python or Javascript. In some respects that
should be easier: translated functions can be tested to work identically.

------
hbbio
The current Dart buzz shows merely two things: (1) There is a need for better
languages to program web apps. (2) Google marketing power is impressing.

But, technically what Dart introduces is nowhere new. Have a look for instance
at Opa (<http://opalang.org>) which is open source and already does more than
Dart. If you take out the marketing bulls... that it is going to replace
JavaScript, when it now just compiles into JS as many other do.

~~~
mabdt
It looks like the website dartlang.org is down. I hope it will be up again
soon so that we can compare the two languages in details.

------
indigoviolet
[http://googlecode.blogspot.com/2011/10/dart-language-for-
str...](http://googlecode.blogspot.com/2011/10/dart-language-for-structured-
web.html)

------
seddona
You guys need to check out ActionScript, your re-creating it.

------
krosaen
It's interesting that dart provides the translator at the html level, which
allows dart to support direct inclusion of dart scripts in an html page, and
for one dart script to require another.

However, it seems like this would actually make it harder to package up dart
script files efficiently to minimize multiple http requests; it would be nice
if dart had some way of emitting a single packaged up dart file as part of the
html translation process.

------
yannis

         class Sunflower {
     
           static void main() {
             new Sunflower();
           }
    
    

No thank you! I would rather stay with prototype objects.

~~~
clownz0r
Not sure exactly what your problem is since that code won't even compile

~~~
yannis
It's from the documentation
<http://www.dartlang.org/samples/sunflower/index.html> ...

------
wbhart
Hmm.

print('${(1<<31)}'); -2147483648 (correct value is 2147483648)

print('${(1<<30)+(1<<30)}'); 2147483648 (correct)

print('${(1<<30)+(1<<30)+(1<<30)+(1<<30)}'); 4294967296 (correct)

print('${(1<<30)x(1<<30)x4}'); 4611686018427388000 (correct value is
4611686018427387904)

(I've used x instead of star here as the latter does not display on HN.)

This is completely nonsensical.

~~~
cromwellian
It has the same numeric semantics as Javascript. Javascript does not have a
64-bit integer.

~~~
wbhart
This is not about the lack of 64 bit integers. Dart can have 32 bit or 31 bit
or 30 bit integers or whatever it wants.

But mathematically it doesn't make sense to have an int type which does not
represent integers consistently. Clearly Javascript can represent 2^31 as a
positive integer. In fact it can represent 2^53 as a positive integer (of
course in reality it uses a double precision float) as can be verified by
typing (1<<20)x(1<<20)x(1<<13) into a Javascript console.

So why is (1<<31) not positive? This is surely something which needs to be
fixed in Dart. If they want to make (1<<31) negative, then (1<<30) + (1<<30)
should equal (1<<31) and so it should also be negative. Otherwise doing
arithmetic is difficult and error prone, which makes it unsuitable as a target
for other languages which want to compile down to Dart.

In fact, not having at least 32 bit unsigned integers would be a major
drawback. For efficiency reasons you want these to be handled directly by your
VM using integer assembly instructions. This is the only way that you'll ever
implement efficient bignum libraries for example which require FFT's which
necessarily use integers that are an exact multiple of 32 bits in length (Z/pZ
for p = 2^(2^L) + 1 usually, where 2^L is a multiple of 64 at least, usually).

------
shn
Has programming language creation maniacs took over Google or what? What
happened to Go. Why Google thinks that they can steal our precious time with
these stuff. Why don't they eat their own dog food first and benefit from the
nutrition and then develop sense of urgency to share it with world! I even
regret to take time to write this comment.

------
vjeux
Here's a little valid Ascii art program with Dart

    
    
      main() { var _ = 1;
      ;;;;;;;;;;;;;;;;;
      ;;             ;;
      ;; ( (){ }() ) ;;
      ;; (_  ^_^  _) ;;
      ;; {;  _|_  ;} ;;
      ;;             ;;
      ;;;;;;;;;;;;;;;;;
      }
    

<http://try-dart-lang.appspot.com/s/y8YO>

------
antimatter15
It seems that the "hello world" dart example compiled into Javascript takes up
538KB (though after closure advanced compilation, this drops to 30KB - still
much larger than the 20 bytes of JS).

Unless the compiler is improved a lot, dart->js' runtime overhead probably
makes it impractical for any app less than gmail-size.

------
LeafStorm
It seems to me that Dart is to JavaScript as Vala is to C. Both Dart and Vala
compile to their target languages, have syntax similar to their target
languages, are additionally influenced by relatives of their target languages
(Java for Dart, C# for Vala), and add an object system onto their target
languages.

------
timtadh
I was honestly hoping for an Open Intermediate Representation of web languages
to be part of the announcement. One that both Javascript and Dart could target
so developers could ship binaries to the browser. I am disappointed in the
language and I am disappointed in the lack of imagination from Google.

------
dongsheng
Looks like an extended javascript with strong typing and more OO support, is
it designed to replace javascript?

------
roman_vorushin
It seems to be very misguiding when designers of some new programming language
are heavily biased with some business needs or platform selection.

Programming language is not just a technology. It's a way of communicating my
thoughts. I don't want to think and write (and read!) in just an _efficient_
language.

------
grimlck
The incorporation of bignums is interesting - i'm curious how does that works
when compiling to javascript (where double is the only numeric type)

does that mean all integer math is emulated? Long emulation is slow enough in
GWT, but you have the choice of using int if you don't need a long.

------
gabyar
Wow, indistinguishable from java. Statically typed and uses generics. Are you
kidding me.

Dear Google: seriously? :(

------
dasmoth
VM snapshots for fast startup are potentially nice. But what's the format
going to be like? Any realistic chance this will work with multiple browsers?
Would need to be something closer to Java serialization than LISP-ish VM
imaging.

------
sek
Erlang style actor model and OO? I can just say awesome! The possibilities are
endless.

------
petercooper
I know many HN readers subscribe to my JavaScript, Ruby, and HTML5 newsletters
so a public service announcement.. <http://dartweekly.com/> is up and will be
publishing soon :-)

------
jroseattle
I fail to see what Dart accomplishes that other languages don't already
accomplish. Not just syntactically, but all things considered -- runtimes,
compilers, etc.

Sorry to be critical, but this looks like technology for technology's sake.

------
desireco42
Isn't this what coffeescript is, just that cs does it 100 times better

------
malbs
static methods, inability to add behaviour to base objects, no metaclasses

It's early days, and they haven't presented yet, but son I am disappoint.

I guess I'm not super-excited about it because I was expecting something
revolutionary, but when you think about where they're coming from, it was to
be expected. Lars and co are simply building on V8, so it makes more sense
that Dart is some sort of improvement on javascript, rather than something
entirely new.

~~~
malbs
but +1 to noSuchMethod()

------
vjeux
It doesn't look like to support JSON anymore: <http://try-dart-
lang.appspot.com/s/86QN>

~~~
clownz0r
This works though: <http://try-dart-lang.appspot.com/s/M1wN>

It just doesn't have the syntax for maps that javascript has for objects.

------
topbanana
I was expecting first class language support for asynchrony, to get away from
nesting and error handling JS hell

------
pajju
And this website is not written in Dart.

------
swah
There is something magical about programming languages, and I just felt
motivated to continue studying PLP.

------
velagale
I see a lot of comments on : braces, semicolons ? Do they really matter for
serious programmers ?

------
frzn
Will this language gain more traction than Go? What do you think?

------
jcapote
Why do languages still require semicolons in this day and age?

------
mkramlich
curly braces and semi-colons: welcome back to 1985 again! _yawn_ I return to
the snake.

------
Andi
YAPB Yet another programming bla-nguage

------
zohebv
From whatever little I see, I am already hating it :-) This looks like Java
for Javascript, if that makes any kind of sense. We are in the year 2011, PL
design has progressed so much since 1990 that such an anachronism is
unpardonable. I sincerely wish that companies like Google focus on hiring the
right kind of person for designing programming languages.

What is frustrating is that there are so many people who can do this job
right, yet we are stuck with amateurish programming languages designed by
companies like Google. Please try and hire people like Oleg Kiselyov, Simon
Marlow, Erik Meijer or some one from the possible hundreds who have worked
deep in PL theory for literally decades. On the face of it Gilad Bracha has
great credentials, credentials that would make the HR folk happy but one look
at some of the stuff he writes and we know things are not going to be good.

[http://gbracha.blogspot.com/2011/06/types-are-anti-
modular.h...](http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html)

I think Phil Wadler gave him more respect than was due in the comments :-)
Microsoft hired Anders Hejlsberg for .Net which I don't think was a good idea,
he is a great engineer but not a PL theory expert. They however "rectified"
the situation by hiring Erik Meijer later and his impact via LINQ and F# and
improvements in C# is obvious. Not to say that Hejlsberg is not good, but
Meijer is better. Getting back on track, I may be wrong but Dart makes me
groan. It is one thing to design such a language in 1990, but quite another
thing to do it in 2011.

~~~
nzonbi
Agree with parent comment. My opinion, so far:

Overall: uninspired. Below what I was expecting. Probably good for Google
goals (tooling, migrating developers, etc)

The language is somewhat interesting, but unfortunately saddened by an
incredibly boring syntax. At this point, I am thinking that they would have
been better off just going with the Go language for this. Looks like something
good to migrate fleets of java engineers to, but not something that would
inspire "hackers".

Now I feel like it is not worth to create any "brigthly" IDE whatsoever. Just
go with eclipse.

I was planning to immediately rush to the language. But changed to wait and
see now.

Misses:

    
    
      - Incredibly uninspired, boring Java-like syntax.
      - Not everything is an expression.
      - Java-like classes, instead of anything more interesting.
      - Lacks simplicity, symmetry and beauty.
      - Semicolons.
    

Some notes:

    
    
      In Dart, you can often create objects directly from an interface, 
      instead of having to find a class that implements that interface
    

What?? Why to blur the concepts of classes with interfaces and introduce a
quirk? Beauty comes from simplicity and symmetry.

    
    
      named constructors:
      var greeter = new Greeter.withPrefix('Howdy,');
    

Mildly interesting.

    
    
      Every type in Dart is public unless its name starts 
      with an underscore ("_")
    

I laughed at this. I always have hated the practice to start with "_" for
supposed private variables, in languages without true private. I like it this
way in Dart. My little favorite syntax feature until now.

~~~
arctangent
I agree with you about the syntax - I was hoping for something more like
Python.

Perhaps this is by design, though? Presumably the syntax doesn't look too bad
to people who spend all day writing JavaScript (i.e. the target demographic
for this language).

Presumably some bright spark will eventually write a Python-to-Dart compiler
and then we'll all be happy :-)

~~~
rdtsc
> I was hoping for something more like Python.

Me too! We already have a very readable, simple and elegant language, let's
use that. Anyone know why that wouldn't have worked? (Not using the current
CPython implementation but maybe the same syntax but with a different (web-
only) set of libraries, that is...)

~~~
nailer
That's almost exactly what coffeescript is.

With Source Mapping in browsers, it also means you'll be able to get a .coffee
line in your tracebacks too.

~~~
rdtsc
I agree. Yes, I would have liked to just have coffeescript as their new
language. Maybe they could have just supported direct native execution on
Chrome. Maybe Firefox would have followed.

~~~
LeafStorm
CoffeeScript solves most of the problems with JavaScript's syntax, but the
problem they're trying to solve here isn't the syntax, it's the structure and
semantics.

------
dextorious
From the very first comment: "We are in the year 2011, PL design has
progressed so much since 1990 that such an anachronism is unpardonable."

It's meant to be a language for web development. Catering to the HUGE,
EXISTING javascript dev crowd and meant to work with javascript (compile to,
reuse staff) etc.

Can we please remove our blinders for a little while and stop whining that
it's not like Haskell or any other flavor du jour?

------
Andi
I want node.dart. NOW!

------
IdeaHamster
Is there a reason they didn't just call this ScalaScript?

~~~
micrypt
Because it's nothing like Scala?

~~~
samstokes
That didn't stop them calling JavaScript JavaScript...

~~~
Sandman
A mistake that should not be made again.

------
skrebbel
A language that compiles to JavaScript really needs better browser support.
Decent web apps use feature detection to provide graceful degradation for
browsers from the stone age. Dart breaks this by making it impossible to run
any code at all.

I mean, "IE9 support coming soon!", what the hell? What about IE6? This isn't
a CSS style or an animation library we're talking about.

~~~
cromwellian
This is not a product launch.

~~~
skrebbel
The lack of browser support implies architectural choices that will always
make old browsers lag behind. It means that the generated JS uses modern JS
features. If it would be easy to support older browsers, they would've done so
already - at least to _some_ extent. The fact that it compiles only to JS for
the very latest versions of a small number of browsers gives me the impression
that a lot of language/compilation choices are closely tied to these new JS
features. This, in turn, implies that supporting older JS versions is non-
trivial.

Maybe I'm wrong, that'd be nice.

~~~
cromwellian
Or maybe they've only been working on this thing for a few months and were
slavishly fixing bugs right up to the announcement, and IE6 support wasn't
really a priority?

Except for Isolates -> WebWorkers, there's not really anything that can't be
emulated in IE6. GWT has to handle a significantly more complex set of
semantics and still works on IE6.

But personally, I prefer if there wasn't IE6 support, or any non-HTML5 browser
support for that matter. If you're going to do a new VM, do a clean-break,
because legacy support is another factor which makes web development a pain.

