If I had to describe Dart in one word I would use – mediocre. I've listed some points that I liked and disliked over year and a half of using it below.


Every Class is also an Interface

One of my favourite parts of Dart is that every class is an interface, it's a very powerful mechanic which saves a lot of effort.


Dart was developed by people from Google, and like Angular, Karma, Go and other projects made by Google it has a well implemented testing framework and tools.


Generics and Typing

By standards of the 2015 Dart's syntax can be thought as conservative, it has some advances in comparison to JavaScript and Java, but Scala or Ruby circa 2010 will blow it to pieces. My main concern is typing thought:

LinkedList<LinkedList<Future<File>>> gridTiles;
LinkedList<LinkedList<int>> gridWeights;

If Dart would declare types after field name like in Scala, ActionScript or Go situation would improve:

val gridTiles:List[List[Future[File]]];
val gridWeights:List[List[Int]];

While it has an extra word ```val``` all field names are at same column, and it's easy to find field names simply by moving eyes vertically. When using Dart, eyes have to move both horizontally and vertically to find fields with specific name. It's a minor complaint, I hear people live with this shit in Java world, but in year and a half of using it started to annoy the hell out of me lately.

Second problem is that we don't have algebraic types, I won't go into computer science, but it would help with cumbersome generics. Actually after using Scala, I something wonder if designers of Go made a correct decision to abandon generics, they seem to be good tool on paper, but once implemented they<tend<to<make<your<code<hard<to<read>>>>>>>>.

Another thing that I actively dislike in Dart is library definition and import syntax. When defining libraries both main library file has to list all files that it uses, and then each file has to specify which library does it belongs too. I find it to be an example of unnecessary defensive programming, I don't remember ever having a problem that this syntax would prevent. Imports break into three categories too, local, packages and core dart, even Java manages to have single import syntax for everything.


Programming language discussions can be tricky, some people talk about compilers as if they are part of language, while other think that everything outside of language specification document is off-topic. But in case of Dart, standard library is an important part of it, and there is a big problem with it. Few months ago Jesse Warden asked if people were happy with event streams in Dart, and I mentioned that I wouldn't let junior developer touch them, they are complex sons of a bitch, and that's a big problem when it comes to something as integral to development as event model.

Futures are better, in fact their implementation is much simpler and better than JavaScript's promises, I still think that whoever implemented Promises in JavaScript be punched in the face.

And So So


I have mixed feelings about collections. Python, Erlang, Lisp-likes and Prolog live and perform well with basic list types. But then having low-level implementations of Lists and Maps can help performance. But god dammit, what happened with perfectly good word "Immutable", why do my eyes have to look at UnmodifiableListView and UnmodifiableMapView.

Package Manager - Pub

Good, not great, was developed from scratch after NPM and not as good as NPM, I expected more from it.


Documentation lacks examples in a lot of cases. It's on par with a lot of other languages but inexperienced programmers would need additional literature to make sense of how to actually use language.

Syntax Sugar

It's not impressive, as I mentioned above it looks quite conservative when compared to modern languages, but it's there and it helps. It could've been better though.


If you know and like ActionScript, Scala and alikes and miss static typing in JavaScript, then Dart is good. But nothing about it is great and it's not friendly for anyone who doesn't have "Senior" in their job title.