Dart : Dead or on Bullseye?

bullseye-926864_960_720                                                   [Image source : pixabay.com]

Around late 2013, Google announced 1.0 of its own programming language Dart targeted initially at the web. But since then, it didn’t receive much attention like other modern programming languages. A bunch of enthusiasts started using it and found it interesting. But as it was targeted against the web (and therefore the javascript) initially, it also received much hate. Some people also marked it dead. In late 2014, I picked it up and just did some experiments for a while. It is truly a cool language from a Java background. In this post, I will express some of my opinions about what went wrong with the language, what is still good and why the language still has the potential. It may be more opinioned and it is how I feel about the language.

What went wrong

Targeting the only web

Initially, Dart was targeted ‘only for the web’. This strategy didn’t work fine. The web development community is horribly fragmented. Also, nobody wanted another language in the web community. There are dozens of programming languages that compile to Javascript like CoffeScript, TypeScript, Scala.js, PureScript, Elm, Haxe, etc. Dart has no reason to be chosen over all of these.

Misunderstood Type System

Type systems are always a matter of controversy in programming languages. Many people would agree that dynamic typing makes programmers productive but when it comes to scalability in software, static typing is necessary. Everyone love experimenting at first. Static typing makes experimenting hard. Everyone need scalability at last. Dynamic typing makes it clumsy.

Dart’s type system is cool. It has an optional type system where you can start with loose typing and then specify the types later. The real benefit of it is that you can gradually evolve programs. At first, you can start prototyping without types and then add types later.

However, the type system was initially marketed like a combination of JavaScript and Java. Of course, Dart has Javascript-like syntax and Java-like standard libraries but the goal of optional type system was clearly not that. Many devs thought of the language as some sort of combination of Java and JavaScript. Of course, anyone would not want to put their efforts or money to learn  or use a combination of two another languages. Instead, why not they just learn those languages?

Javascript-like syntax

Dart creators said that as they are targeting for the web, they wanted to keep the syntax familiar to Javascript developers. JavaScript has the syntax similar to languages like C, Java and C#. They are all old languages. Of Course, there are many improvements in Dart like good functional and async support etc. But there are no syntax improvements.

Instead, with that verbose and old syntax, Dart feels boring. There are numerous things still needs to be improved in the language itself. The braces for named parameters and square brackets for optional parameters feels ugly and unreadable. Many modern languages like Swift Kotlin and Go did a good job of removing unreadable and repetitive stuff like ternary expressions and prefix increment decrement operators. There is inconsistency even in type names. Is there a reason for writing String in upper case and int in lowercase even if they all are objects? Why there are numbers and integers both? The underscores for private members suck. Most modern languages give importance to the readability of programs more than writing. Tiny details are important. If everything is put in a language has no solid reason for doing that, that’s a bad thing.

What is still good

Standard Libraries

Dart SDK provides a complete standard library with built-in collections, futures, streams, asynchrony and much more. So, you don’t have to rely on any external modules to do basic (probably most) things. This is also true for any programming language born at Google, take Go for example.


Dart plug-in for IntelliJ IDEA community edition works fine. Tools for the formatting and analysing code – dartfmt and dartanalyzer are also available. The Dart Observatory is really a big deal.


Starting with Dart is easy.  I like getting started fast and experiment a lot. Fairly, I like the idea of an optional type system. Optional typing helps a lot here. With all the built-in libraries and good tools, it is easy to build a good app without bothering yourself about searching libraries for basic things. Experimenting is always fun without those type-heavy systems and later I can turn those experiments into structured programs, which is really a cool thing about Dart.


Dart is a very productive programming language and has a great potential but a bunch of bad decisions and circumstances turned the language away from being popular. Dart was always designed as a ‘general-purpose’ programming language. Dart creators have already realised these things and Dart now wants to take on all the client-side development including browsers, mobile platforms and embedded devices. As the language has already failed to meet the expectations, there is a good room for improvement. At this moment, Flutter and Dartino are being mature and we just heard a brand new mysterious OS named Fuchsia that will use Dart as a front-end for building apps. Dart developer summit 2016 is nearby in October and we can hope to see what is next. Personally, I am excited about Dart 2.0.



Random thoughts on modern programming languages and Go

When I started my career as a developer, it was about last year of my graduation. At that time, I was like a Java fanboy. I fell in love with Java while studying it. Honestly, It felt very natural as a programming language. (and don’t get me wrong – I still really like Java) When I started working on real projects in my early days of the career, I realised that there is much to learn about programming languages & their semantics. I worked with many smart people and introduced to a whole bunch of new techniques, patterns, libraries and tools to build software in the fast and efficient way. It was a good and overall very enjoyable learning experience but I also passed through some of the issues about the current state of programming.

The Problem with Black box Abstraction

When I started building apps, I was introduced to some popular libraries that are recommended to use for general stuff like networking, databases and image decoding etc. I am very curious and so I always tried to find out how some big libraries works under the hood. I tried to look at their GitHub repositories and navigate to some code and tried to understand how it does some XYZ things. It was very beginning of my career and I always failed to fully understand how they do. So, I asked to some of my colleagues and some of them replied:

Who cares how it does something? It always works”

“You just need to learn about how to to use them. Don’t worry about inner details”

The library is just someone other’s code that provides an abstraction on certain things to make our life easy. But the point is why it is harder to read code than to write it? Why sometimes it becomes difficult for a beginner to look at someone other’s code and reason about it? Is it because the code is written as that one may get confused. or is it because one may not know certain design patterns used in that library? or is it because the programming language itself can do many things in many ways that one doesn’t know about them?

Almost every beginner and most end programmers tend to use libraries and frameworks without understanding how it does something under the hood. They see them as a black box. The black box that does certain things for them and make their life easier.

This is a big problem. Most of the times, it takes more time to understand someone’s code than writing it by yourself. This is why code reviews are taken more around code quality rather than software architecture or performance. Readability is the only most important thing considered while taking code reviews.

I don’t think that libraries and frameworks should provide the abstraction in such way that hides the details of the underlying system. Rather, they should provide the abstraction in a way that people can actually understand the underlying system. Too much abstraction becomes a barrier for most people, especially beginners to actually understand what the system does. It makes them think more about doing things rather than going deep and understanding things. That’s not a good thing. We want people to actually understand the details of stuff under the hood, not to learn the ways of using things. Anyway, this is my opinion and not everyone would agree on it.

The main reason behind all of the things I think is the current state of programming languages. When you look at some of the old programming languages like C++, JavaScript or Java and newer programming languages like Swift or Kotlin, you will realise that they are adding more and more features from one another and thus gives more ways of doing the same thing. This leads to writing program easily and faster but makes programs more complex and harder to reason about. Some people says that it makes programmers more productive. Adding more features to the language is not the only thing that makes programmers productive. When the codebase becomes large, sooner or later people realises that it could be made simpler if it had to deal with fewer ways of doing same things.

Learning Go

For the last couple of months, I have tried many new programming languages. I tried Dart and Kotlin. I looked at Rust and Swift. I like them. They all are feature rich. But they all forces you to think the same and believes that it is the standard paradigm for building good software.

Then, I tried Go. It took me less than two hours to learn the basics of Go. The language is simple and syntax is very much concise. The most important thing I liked about Go is that it has a minimal set of what called ‘features’. For an example, Look at the way of handling errors. At first, it looks very different from a Java background. But when you try it, you will realise that this is the way I should handle the errors. Go is a perfect blend of notions that makes the language very easy for learning and programs more readable for any level of programmer. The way interfaces are used feels very natural. There are no classes and so there is no type hierarchy – the hierarchy that can be broken by subtle changes after decisions. There are no generics. Sometimes I miss them. But when I think as a beginner, I think it is nice not to have them.

The most important thing in Go is that it solves above stated problem. Any beginner can easily read through the libraries and know how it works under the hood. It is very easy to read other people’s Go code and it always takes less amount of time than other languages.

With the current state of IDEs and tools, I feel very productive in Java. But as the second language of choice, I will surely go with Go. :=)