
Dart Is Not the Language You Think It Is - pauljonas
http://programming.oreilly.com/2013/05/dart-is-not-the-language-you-think-it-is.html
======
mratzloff
Who is the audience for Dart? Clearly it is first and foremost Google, whose
programmers spend their days writing Java and C++ in an IDE like Eclipse. But
web developers, who are the primary producers of JavaScript, will happily
stick with Node.js, CoffeeScript, or plain JavaScript.

For that audience, they are given a language with optional static typing (most
don't want it) and an Eclipse-based editor (most don't want it).

By way of contrast, consider Go. Go is (in my opinion) an extremely successful
successor to C, in terms of its design. It fixes a handful of problems with C
(strings, and I would argue pointer arithmetic), and modernizes and
streamlines it. The interface system is fantastic. In terms of its design, I
have nothing but good things to say about Go.

Dart does not seem to improve on JavaScript in a compelling way. It adds
optional static typing, and as far as I can tell, nothing else.

Is it any surprise that Dart has failed to take off?

~~~
timothya
_IDE like Eclipse_

You don't need to write Dart in the Dart Editor if you don't want the IDE
experience. I happily write Dart in Sublime, and Dart has command-line tools
that I can use to validate the code that I write.

 _But web developers, who are the primary producers of JavaScript, will
happily stick with Node.js, CoffeeScript, or plain JavaScript._

If web developers are happy with the tools they have, then that's just fine.
The Dart team isn't trying to replace JavaScript, but instead provide another
option for web development. What I think the Dart team is finding is that
there are a lot of people that are having trouble with putting together all
the pieces just to build a web app. This is especially true if you are new to
the web platform, and you're familiar with the development from other places.
Dart provides a very consistent platform that you can build web applications
with, and you don't need to worry about jumping through all the hoops that
normal web development requires.

 _By way of contrast, consider Go. Go is (in my opinion) an extremely
successful successor to C, in terms of its design. It fixes a handful of
problems with C (strings, and I would argue pointer arithmetic), and
modernizes and streamlines it. The interface system is fantastic. In terms of
its design, I have nothing but good things to say about Go._

In a way, this is how I see Dart too (though Dart is a much newer platform,
not yet out of beta). Dart aims to fix a handful of problems with JavaScript
(like better scoping semantics, a built-in module system, better toolability
and static analysis tools, etc.), and then also takes the existing browser
APIs and modernizes and streamlines them (for example, all of the core browser
APIs use a consistent Future-based API for asynchronous values, which cleans
up a lot of messy code that you'd ordinarily see in JavaScript web application
code).

 _Is it any surprise that Dart has failed to take off?_

It's not at 1.0 yet. I still think there is plenty of room for improvement,
and plenty of time for adoption.

~~~
kamaal
>>You don't need to write Dart in the Dart Editor if you don't want the IDE
experience. I happily write Dart in Sublime, and Dart has command-line tools
that I can use to validate the code that I write.

This is the same line argument made with regards to Java too.

But the fact of the matter is, these language bring in so complexity with
their whole ecosystem. Working without an IDE isn't even worth that torture.

~~~
timothya
Respectfully, I disagree.

I've written Java in plaintext editors before, and that is truly terrible.
Dart is nowhere near that verbose. Dart's imports feel pretty lightweight
(rather Python-esque) and the fact that the language has top-level functions
and variables means that you're not always trying to juggle a bunch of classes
and objects and interfaces when you don't need to. In fact, Dart's style guide
explicitly recommends that you don't put things in wrapper objects just
because you can. <http://www.dartlang.org/articles/style-guide/>

I really don't think that Dart brings in any more complexity than you'd have
in a JavaScript application. I actually think it's a lot easier to hold a Dart
application in your head because all the APIs have a consistent interface.
With JavaScript, you often have a bunch of different libraries and you have to
remember how each of them behaves.

------
ChuckMcM
This I didn't get:

 _"Dart is a source code VM

The Dart VM reads and executes source code, which means there is no compile
step between edit and run. As with other popular scripting languages, it’s
very quick to iterate with Dart. The Dart VM runs on the command line and
servers, and can be embedded into browsers. Just point the VM at Dart source
code and you’re up and running!"_

By that definition Dartmouth BASIC is a "source code VM" aka an interpreter.
Why call it something it isn't?

I think Dart is interesting in its own way, and generally a useful exercise
for thinking about how you might write an interpreted language that can run in
untrusted contexts, but beyond that I don't "get" the problem it is trying to
solve.

~~~
rtfeldman
The problem it's trying to solve is that Google's JavaScript optimizing team
is hitting the limits of what they can do to speed the language up given the
constraints imposed by JS.

They want a replacement language that's more optimization-friendly so that
they can continue pushing for faster Web clients.

Given this creator goal, and most programmers' goals of "use a language that
better suits my needs," it's not terribly surprising that Dart hasn't seen the
kind of community interest that CoffeeScript has.

~~~
spankalee
That's not the only problem Dart is trying to solve. Productivity and the
ability to build good tools for the language are huge factors in Dart's
design.

That's why it has libraries, type annotations, a declarative top-level
structure, and some of the reason for closed objects. Good tools for Dart are
_much_ easier to write than tools for a very dynamic language.

------
willlll
Untyped languages are okay. Typed languages are also okay. Typed languages
with inference are okay.

Optionally typed is extremely strange.

~~~
mythz
Dart's optional typing is effectively a dynamic language that allows you to
decorate your source with optional Type info that effectively just acts like
documentation for other developers and automated tooling.

It's far more readable and concise having it embedded in the language rather
than buried and disjointed in the comments. Not to mention it also allows for
superior tooling support.

I've personally been extremely productive with Dart (most productive I've ever
been with any language). It's effectively a more consistent JavaScript with
less ceremony with the benefit of optional typing which has caught errors on a
number of occasions, giving instant feedback and identifying errors before
I've even run the code.

~~~
kvb
As long as you're adding a type system (optional or not) it does seem a bit
odd to opt for an unsound one...

~~~
mythz
makes sense if you prefer dynamic languages since it adds least friction.

~~~
lucian1900
You can always have the Any type + a runtime tag on the box if you really need
it.

~~~
mythz
That's just var (i.e. un-typed) in Dart.

------
oakaz
Here is what I think about Dart: it is huge and is another programming planet
that you can't reuse what you already have (like thousands of libraries in
NPM).

And the most important part; it looks boring. the articles about it look also
are very boring.

~~~
timothya
_Here is what I think about Dart: it is huge and is another programming planet
that you can't reuse what you already have (like thousands of libraries in
NPM)._

Dart has a js-interop library for the times that you want to reuse some code
written in JavaScript. This video gives a good introduction to it:
<http://www.youtube.com/watch?v=QFuCFUd2Zsw>

_And the most important part; it looks boring._

That's was a big design goal when they created the language. It's designed so
that, for the most part, it looks and behaves like other languages that you're
used to. You can pick it up in an hour or so and be productive right away. The
Dart team didn't want to create some esoteric language with all sorts of crazy
features, they set out to create a real language that people would feel
comfortable using.

------
tnuc
Dart is exactly the language that I think it is.

It is too bad that it doesn't run on many browsers but that isn't going to
change.

What is the point of using Dart other than to join Google's garden of ugly
walls?

~~~
spankalee
Dart runs on IE >= 9, Firefox, Safari and Chrome. Why is that "too bad"?

~~~
LVB
The JavaScript output runs on all of those browsers, but only Chrome (or
actually the special "Dartium" version of Chrome) has a VM to run Dart code
directly.

~~~
spankalee
Why does that matter?

Dart brings improvements to the language and tools that are worthwhile
regardless of the VM being available in the user's client. dart2js is the
primary method of deploying Dart code, and there's nothing bad about that.

~~~
pjmlp
It does not bring any advantage to the plethora of languages that already
compile down to JavaScript.

~~~
afsina
Most of them's tool support does not even compare to Dart. Dart code can run
directly in Browser for the starters, multiple strong IDEs, sane debugging and
modularity support.

~~~
pjmlp
Like Amber, TypeScript, F#, ....

~~~
afsina
All require javascript compilation for development AFAIK

~~~
pjmlp
Like Dart, because it will _never_ be adopted by other browsers.

~~~
spankalee
He said "for development". The nice thing about the VM in Dartium is that you
don't need to compile as part of your development workflow until you need to
QA and deploy, just edit and refresh. You don't need the VM in consumer
browsers to get that benefit.

------
barabaraphil
The language looks great. The challenge I think is always building enough of a
community to create a rich enough stack that people can build real-world
applications on. Scala did a fine job there, and a lot of that had to do with
some companies taking some ownership of the platform (TypeSafe in that case),
which may be good and/or bad. I wander what others think of this.

~~~
melling
Your little typo "wander" instead of wonder kind of demonstrates the point of
Dart. It's a language that seems to provide more of a safety net for
developers. We all make trivial mistakes, probably daily. It's nice to have a
little more support in a language to help us along.

Throw in the extra performance (2x?) over Javascript and I'm ready to at least
give it a try.

~~~
sethladd
[disclaimer: I work on the Dart team]

The Dart VM is 2X faster than V8 on a few benchmarks already. Check out
<https://www.dartlang.org/performance> We've still got a bunch of work to do,
but the initial results are encouraging.

------
mythz
For those interested, a great place I've found in keeping up with Dart
announcements and to get in touch with the Dart community is on Dart's G+
Google Group:

<http://g.co/dartisans>

------
snomad
I really like the feature set and feel of Dart. My only concern is lack of
browser support.

As of May 2013, Microsoft Internet Explorer, Mozilla Firefox, Opera Software's
Opera browser, and Apple Safari have no plan to embed a separate Dart VM [1].

What would it take to get these vendors to add support?

1:
[http://en.wikipedia.org/wiki/Dart_%28programming_language%29...](http://en.wikipedia.org/wiki/Dart_%28programming_language%29#Browser_adoption)

~~~
timothya
_My only concern is lack of browser support._

Because Dart compiles to JavaScript (which can even perform better than
handwritten JavaScript to perform the same actions[1]), it runs everywhere.
You don't need the Dart VM built into a browser for your Dart application to
work; it already works today.

 _What would it take to get these vendors to add support?_

I think that likely they would want to see more applications written in Dart.
If a big company (like Facebook, for example) wrote a large application in
Dart, other browser vendors would see both that big name developers are using
Dart for their applications and they'd see the performance boost that browsers
with the Dart VM built in take advantage of[2]. This would make it more
compelling for them to include a Dart VM in their browser.

[1]: [http://news.dartlang.org/2013/03/why-dart2js-produces-
faster...](http://news.dartlang.org/2013/03/why-dart2js-produces-faster-
javascript.html)

[2]: <http://dartlang.org/performance>

------
shurcooL
I like what I see in the article, but... I'm kinda put off by the seemingly
high barrier of entry. All the tools they show off are great once you've
started, but I don't want to install all that just to try a slightly more
advanced "hello world" sample.

It's really too bad there isn't an equivalent of play.golang.org for Dart. I
would've given it a try right now if the barrier of entry were lower, and
perhaps I'd be pleasantly surprised enough to keep using it.

Also, is it possible to generate and execute Dart code within Dart (the way it
is in dynamic languages like JS) without recompiling?

~~~
ahoge
> It's really too bad there isn't an equivalent of play.golang.org for Dart.

There is.

<http://try.dartlang.org>

Anyhow, the barrier is actually pretty low. The editor zip is about 140MB in
size and contains everything you need: the SDK, the editor, and Dartium
(Chromium + Dart VM).

------
trimbo
I've read post after post about Dart. It looks really neat. I want to try it
sometime.

Now can Google use it to do something big and important? Please? We want to
see that it works for _you_. Invest in it by building products with it and
show us we should do the same.

------
alvivi
So, I've thought for a long time ... if I could take a clean sheet of paper
and write [a new language] that retains all the goodness of [JavaScript] ... I
would not have come up with anything like Dart. - Douglas Crockford

------
uvtc
One thing I'm not too crazy about is that, AFAICT, it seems that you need a
Google account in order to upload packages to its cpan-alike,
<http://pub.dartlang.org/> .

Can the Dart package management tool fetch/install packages which are not
hosted at pub.dartlang.org? Can it install packages straight from a github
repo?

~~~
xxgreg
The pub package management tool allows you to fetch libraries from a git repo
or the local filesystem, see here:

<http://pub.dartlang.org/doc/dependencies.html#git-packages>

------
DomreiRoam
I don't know Dart but I m intrigued by this "Dart is purely object oriented".
Seems that people don't like some fundamental characteristics of javascript:
the functional part and the prototyped based OO style. Is it still possible to
use this in Dart or it is like the author said, purely OO?

~~~
PommeDeTerre
Supporting first-class functions only makes a language "functional" in the
smallest sense.

Functional programming goes far beyond that. It encourages things such as
immutability, referential transparency, powerful pattern matching, the heavy
use of recursion, and robust type systems.

JavaScript either does not support such techniques and concepts, or it makes
them difficult to use. Thus it is improper to consider JavaScript a
"functional" programming language.

The same goes for JavaScript's so-called support for OO. Prototype-based OO is
one of the least-useful approaches to begin with, for real-world software
development, and JavaScript even manages to implement it quite badly compared
to other languages offering prototype-based OO. JavaScript's complete lack of
class-based OO (although, we may see this change with future revisions of the
language) further suggests that it's wrong to call it an "object-oriented"
language.

I'm not sure we can even make this comparison. JavaScript is, at best, an
imperative language that has tried, rather poorly, to partially incorporate
concepts from more advanced programming language paradigms. It's hard to
imagine Dart, or any other language, supporting more advanced concepts any
worse than JavaScript already has.

------
stcredzero
How about a virtual machine facility that outputs what the types of variables
are at runtime, combined with tools that can collate data from many runs and
apply consistent types back to the original source code?

~~~
dietrichepp
That's dangerous, because you have no way of knowing if you have 100% coverage
without doing static analysis, and if you double check everything with static
analysis, you might as well only do the static analysis in the first place.
(Static analysis won't always give you an answer, but it won't ever give you a
wrong answer.)

I am reminded of the folks who optimized .kkrieger, which is a 95 kB first-
person shooter. See "Metaprogramming for Madmen":

[http://fgiesen.wordpress.com/2012/04/08/metaprogramming-
for-...](http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-madmen/)

Some highlights: during the test run, the player never pressed the up arrow
key in the menu, so that functionality was removed by their tools. Enemies at
the beginning never hit the player, so the code which handles damage was
compiled out. And the system used a certain brand of graphics card, so code
necessary for other graphics cards was compiled out.

The lesson is: don't let tools change code semantics based only on black-box
testing.

~~~
stcredzero
_> That's dangerous, because you have no way of knowing if you have 100%
coverage without doing static analysis_

You are right from a theoretical standpoint, but I'm not so sure this fits
with how web applications are known to run and the patterns development
usually follows.

Developers who shove an object of one type in an instance or temporary
variable one time, and a different one another time are usually doing
something bad, even in dynamic environments -- unless there is a specific
interface involved. Just because "duck typing" is fast, doesn't mean that it
has to be loose.

The point, actually, is to discover where types are being misused as much as
to discover what the types are.

 _> The lesson is: don't let tools change code semantics based only on black-
box testing._

I'm also advocating this. However, it seems like you're mainly familiar with
dealing with types in statically typed environments. In dynamic environments,
the developers still need to know the types. Often, there are hard and fast
rules only enforced by convention. This is indeed a source of errors, but by
and large, programmers are very good at managing this. In other words, very
often, the programmers will _know_. I see environments like Dart as a way to
eliminate such conventions, but still enable very fast prototyping in the
beginning. (Ultimately, static types are better for maintenance.)

------
andyl
To me Dart looks like another brick in Google's walled garden. Weakening
support for XMPP, Webkit, RSS, and JavaScript. Investment in so-called open
technologies like NaCL and DART that are controlled by Google and optimized
for Google's platform. Too bad.

~~~
mythz
Walled garden??

It's the most open language I know, fully OSS'ed with an extended license to
include any implicit patents (removing Patent FUD), developed out in the open
and accepting 3rd party contributions and inviting feedback to influence
language design.

Lars Bak also mentioned at Google I/O that they're in the process of trying to
get it standardized, not sure what's left to do to make it any more "open" and
inviting.

~~~
oinksoft
Let's not pretend that Google's open source products in any way follow an open
development process. Do you notice anything in common about the recent
committers?

<http://code.google.com/p/dart/source/list>

<http://code.google.com/p/closure-compiler/source/list>

<http://code.google.com/p/closure-library/source/list>

Their development is very much insular. That's not to say it's a poor idea to
depend on these products, but they don't compare to projects like Python with
formal processes for revisions (PEP) or at least some discussion.

It would be nice if Google maintained mirrors on Github and accepted pull
requests and such, but I don't see that ever happening.

~~~
enneff
> Let's not pretend that Google's open source products in any way follow an
> open development process.

You said "product", but you should say "project".

If you want to assess the openness of the development process, look at the
process itself:

<https://code.google.com/p/dart/wiki/Contributing>
[https://groups.google.com/a/dartlang.org/forum/?fromgroups#!...](https://groups.google.com/a/dartlang.org/forum/?fromgroups#!forum/reviews)

If code reviews are happening in the open and there's a process to bring new
contributors on board, that's a great start. This early in the game, you can't
expect random members of the open source community to start contributing more
than a dedicated team at Google.

> It would be nice if Google maintained mirrors on Github and accepted pull
> requests and such, but I don't see that ever happening.

Oh? <http://github.com/google> <https://github.com/dart-lang>

Also, FWIW on the Go project we have more than 300 non-Google contributors and
a solid core of dedicated committers.
<https://code.google.com/p/go/source/list>

