

A Tour of the Dart Language - Mamady
http://www.dartlang.org/language-tour/

======
DanWaterworth
When people say list, I think linked-list. When they say array, I think
contiguous array. I wish we could standardize on that terminology, it makes
sense and allows easy differentiation between the 2 concepts.

~~~
radarsat1
I used to do that, but now I try to think in terms of the abstraction "list"
and "array", and not worry about the underlying data structure unless I'm
specifically thinking about efficiency. For example there are multiple ways of
implementing lists and arrays that have similar interfaces but different
efficiencies for insertion/sort/search, etc. So basically the dichotomy you
propose is just "too simple," it doesn't cover all the options and
combinations that a programmer may need to think about.

~~~
DanWaterworth
I didn't say that it was a dichotomy, actually I tend to think of the space as
roughly split into three: lists, arrays and annotated/sorted trees.

Lists and arrays are really common though, so I think it makes sense to make
it easy to refer to them using short words.

------
quatrevingts
Dart just seems phenomenally boring. Now, I'm not necessarily against boring.
A great synthesis of what we've learned thus far in PL design, breaking no new
ground, but packaging it together into a nice cohesive whole would be very
welcome. But Dart seems like just a minor rearrangement of Java which does
little to make Java faster, safer, or more expressive. Why invest in Dart as
opposed to Java 8 + GWT, or CoffeeScript for that matter?

~~~
spankalee
GWT is pretty painful to use compared to Dart in my experience. Where in GWT
you have long compiles or a very slow Dev Mode, in Dart you have extremely
fast compiles and Dartium which is even faster.

GWT's great when you like static typing, Java development tools, and Java
libraries (which I do, so I use GWT), but Dart give you static typing if you
want, especially with checked mode, and should support similarly awesome tools
because of the typing. Libraries will hopefully come along, and quickly I
predict because there won't need to be the equivalent of jQuery and all the
classical inheritance implementations.

If you're coming from GWT, just think of Dart as GWT but fast, designed to
compile to JS with a native option, and much lighter-weight syntax and
language features than Java.

~~~
quatrevingts
I don't see anything about the language though that would make it
significantly faster to compile than Java... it seems to be a matter of
development priorities for the implementation teams. (Dev mode can be pretty
fast in my experience though, depending on the browser. For some reason there
seems to be major performance issues with Chrome but not Firefox.) If the
effort that went into building Dartium had simply gone into building a custom
VM for GWT, couldn't we have achieved the same thing, but without the
fragmentation? Perhaps Oracle's lawsuits are playing a role here.

------
kibwen
From the (incomplete) overview here (and ignoring the type system for the
moment), Dart appears to be reasonably competent and technically sound, given
that this is a language intended to compile to Javascript. That said, it
doesn't terribly excite me.

It should be interesting to see whether the safety guarantees of optional
typing and the few other restrictions it provides (such as more rigid function
signatures) will really entice developers who are planning large web
applications. I'm working on a modest-sized (~3kloc) Javascript codebase at
the moment and it's somewhat of a mess, but that's really more due to the
combined influence of legacy code, time constraints, technical debt, rapidly
shifting requirements, and a lack of testing. Other than that last point, it's
not immediately obvious how using Dart rather than Javascript would have
benefited me. Perhaps someone who's worked with a more substantial Javascript
application could provide a better answer.

~~~
beza1e1
Dart is not "intended to compile to Javascript". Dart is intended to compete
with Javascript. Compiling to Javascript is just intended as a fallback.

~~~
firefoxman1
This has probably been asked before, but why haven't any browsers worked on
natively implementing CoffeeScript (not compiling to Javascript first)?

~~~
gcp
Because there is no advantage to that at all?

Dart has more type information, so a Dart compiler has some hints to generate
faster code. (And this is why fast JavaScript engines do type inference)

~~~
firefoxman1
Well, I mean, if you're going to try to change the web's language, why not use
a well-thought-out and already widely-used language? Are there so many flaws
in CoffeeScript that Google needed to write yet another language?

------
jhrobert
I'm getting bored with Javascript.

I had a look at Julia and as a result I think that there is some solid value
in designing a language whose performance can match C if needed yet use
dynamic typing when convenient.

I just don't know what to do next: CoffeeScript or Dart?

Both improve on Javascript. CoffeeScript with a cool syntax. Dart with
performance.

How can I have both?

~~~
nxn
Since dart will have to compile down to javascript for any browser that isn't
chrome* , there probably wont be much, if any, performance improvement that
you can depend on. Your only way to be able to use the speed up would be to
restrict your client base to chrome only users. With that said, regular old
javascript is really a much more interesting language by itself than dart.
Perhaps I'm opinionated, but I just don't see anything exciting about Dart.

* This is based on most browser vendors not being supportive of it.

~~~
jhrobert
I just spent a couple of hours reading the Dart site.

Dart is a web friendly optimized SmallTalk with a Javascript like syntax.

It looks like Javascript but feels like SmallTalk.

If that marketing trick works, it will be ironic because Scheme inspired
Javascript looked like Java for the same marketing reason...

CoffeeScript might be Javascript's swan song.

------
pjmlp
Dart will most likely join Wave, followed by Go.

------
islon
The similarity with java give me the creeps... And I'm a java programmer.

------
dgregd
What are pros and cons of Dart support for Mozilla/Firefox?

~~~
kibwen
Dart can optionally compile to Javascript, so a program written in Dart will
run in all browsers, albeit with a fair bit of overhead from the translation
(exactly how much overhead remains to be seen, but Dart code compiled to
Javascript will certainly be suboptimal, or else Google wouldn't bother
implementing a virtual machine solely for Dart).

As far as native support in other browsers, it appears that Mozilla currently
outright refuses to consider it on the principle that Dart is not developed
openly and is not standardized, meaning that implementations in other browsers
would have to reverse-engineer the Chrome implementation and would be at the
mercy of Google with regard to compatibility. Unlike Mozilla, Apple and
Microsoft appear to have rejected it out of pragmatism rather than principle.
Specifically, Apple's Webkit engineers appear to object to the complexity and
overhead a new virtual machine would add[1], and Microsoft has publicly stated
that Dart doesn't solve any problems that can't be fixed in future iterations
of Javascript[2].

For a more detailed technical and political perspective of why Mozilla won't
implement Dart natively, see Brandon Eich's comments on the original Dart
announcement[3] (it's actually quite an interesting read).

[1] [https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018822.html)

[2] [http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-
ecmas...](http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-
ecmascript.aspx)

[3] <https://news.ycombinator.com/item?id=2982497>

~~~
spankalee
_Dart can optionally compile to Javascript, so a program written in Dart will
run in all browsers, albeit with a fair bit of overhead from the translation
(exactly how much overhead remains to be seen, but Dart code compiled to
Javascript will certainly be suboptimal, or else Google wouldn't bother
implementing a virtual machine solely for Dart)._

The overhead of Dart compiled to Javascript will hopefully be very minimal,
and in some cases Dart might generated code that runs faster than what a
programmer might write.

The reason for the existence Dart VM is not because Dart->JS will be slow,
it's because Dart should be able to be faster than Javascript because it's
easier to optimise. The creators of V8 are writing the Dart VM, so presumably
they have some ideas about how to make it faster than Javascript.

~~~
kibwen
Good points. To clarify, by "suboptimal" I meant that the Javascript code
generated by transpiling a Dart application will almost certainly be less
optimal than writing that application in Javascript from the outset. But,
again, whether this will be an issue remains to be seen.

If there _does_ turn out to be significant overhead to the transpilation
phase, I'm curious if a pragmatic subset of Dart will emerge that avoids any
language features that incur expensive tranformation costs, sort of like how
some modern Python projects (e.g. Django) handle 2to3 compatibility by
avoiding language features that are incompatible across versions to achieve a
more unified codebase[1].

[1] [http://groups.google.com/group/django-
developers/browse_thre...](http://groups.google.com/group/django-
developers/browse_thread/thread/abede3685ad0302)

~~~
spankalee
_To clarify, by "suboptimal" I meant that the Javascript code generated by
transpiling a Dart application will almost certainly be less optimal than
writing that application in Javascript from the outset._

My point is that this is not really true. The Dart language itself is designed
to compile to efficient Javascript.

This is one reason it's a better solution than GWT in my opinion, because Java
does not always compile to efficient Javascript and you do have to skip
features like longs, Java regexes, even the java.util collections classes are
heavyweight. Dart being designed from the start to compile to Javascript
avoids most of these problems.

Like CoffeeScript, I expect Dart performance to be very close to Javascript
when compiled, sometimes even faster than what a programmer would normally
write.

