
It's time: bring Dart to Android - DCKing
http://www.grobmeier.de/bring-dart-to-android-03062014.html
======
acron0
So, the author's justification is that Apple now has Swift for iOS, so Google
should bring Dart to Android.

In my opinion, Swift, although great for shepherding more devs onto the Apple
platform, fundamentally directs us further away from the fabled 'write once'
dream. Introducing Dart to Android would just further this back-and-forth
between proprietary platform holders.

And Microsoft, once again, is left utterly bemused, as it decided to focus
away from proprietary languages and allow people to write native apps in
JavaScript. But now people are excited about Swift, so is vendor-specific
languages what people wanted all along?! How confusing.

~~~
gleenn
I think people, or at least people like me, want languages that don't suck to
develop in. Write once is great, but being able to spit some code out without
really old language cruft getting in the way would be nice too. Objective-C
was written forever ago. I don't want to type 30 character method names and
write 6 lines of code to do simple "map" operations. Swift and Dart make these
things better. They are hopefully fast enough to also not make the end product
not suck too. I've worked at at least a handful of companies doing both iOS
and Android and they've all done multiple versions of the same app; these
write-once libraries and projects just don't do it well enough IMHO.

~~~
mpweiher
The long method names really have nothing to do with Objective-C, and all with
Apple's naming conventions...which are the same with Swift.

~~~
weavie
Plus intellisense means its a solved problem.

------
gte910h
I'd say "Bring Scala to Android" would be more comparable? Bring Clojure and
I'd say you're stealing a lot of developers away who think Swift is a half
measure.

~~~
Touche
Clojure already runs on Android, it's just dog slow.

~~~
gte910h
Google didn't bring Clojure to Android, some 3rd party did, and slowly. Scala
appear to have the same story I think? (Large startup lag?)

If you want functional on Android, I'm betting F# is the premiere method today
performant enough to write real apps in.

~~~
logicchains
Performance is not just about the language; Scala and Clojure can be just as
fast as Java on the Oracle JVM or OpenJDK. The Android Dalvik VM is just
incredibly ineffective at optimisation compared to a real JVM, and Google has
done little to improve it. Things might change with the new ART VM, however.

~~~
Touche
Clojure's startup time is super slow even on the JVM. Here's a good analysis
of why: [http://nicholaskariniemi.github.io/2014/02/25/clojure-
bootst...](http://nicholaskariniemi.github.io/2014/02/25/clojure-
bootstrapping.html)

------
eloisant
Or Google could just embrace Scala. You can already use it to develop on
Android, it already has all the good stuff Swift has (and more), you can use
all the existing ecosystem because of the compatibility with Java.

Having it officially pushed by Google would mean better tooling and more
Scala-ish APIs.

~~~
DCKing
Although I _love_ Scala, I don't think it will work as a primary language for
an app platform such as Android. Idiomatic Scala is just too alien for most
people to comprehend quickly.

The beauty of both Swift and Dart is that they are very "light" languages. You
can read a piece of Swift/Dart and see what it's supposed to do immediately.
Most people with a JS/Ruby/Python/Java/C# background can immediately see
what's going on, and probably quickly pick it up. Yet they still provide
productive modern language features. Scala's learning curve is much greater.

~~~
frowaway001
Swift vs. Scala:
[http://leverich.github.io/swiftislikescala/](http://leverich.github.io/swiftislikescala/)

Yes, Swift is pretty much missing the FP parts, but isn't that an argument
about familiarity, not simplicity?

~~~
DCKing
My argument was also about familiarity. The imperative subset of Scala is
really familiar to Swift, you're absolutely right (+1 for posting that
comparison). However, real-world Scala is different. With powerful trait-based
OO programming, its functional style with routinely chaining monad after
monad, and implicits everywhere. It's incredibly powerful, but not an
accessible language for an app platform as large as Android's.

~~~
frowaway001
People can always stick to a style they are comfortable with.

It's perfectly possible to use code which uses "powerful trait-based OO
programming, its functional style with routinely chaining monad after monad,
and implicits everywhere" without having to know that part of the language.

------
Touche
I'm not sure if Dart is the answer, but Google definitely has to do something
about it's "language problem" on Android. Especially with Apple introducing a
modern language in Swift. It's a shame that all of the great JVM languages
don't easily work on Android or they wouldn't have the problem.

~~~
danieldk
I think it makes very much sense for Google to start pushing Kotlin. It runs
on JVMs. It is compiled. It's a simple language to migrate to for Java
developers, but provides more convenience than Java 8. It does not have the
impedance mismatch with Java that some of the other new JVM languages have.
Moreover, it's well-supported by IntelliJ and consequently by Android studio.

~~~
Jare
That would be neat and a very pragmatic choice, but I'm not sure that Kotlin
provides enough of an advantage over Java to make migrating worth for a
significant amount of Android developers. Scala goes a step or two further,
but the overhead (cognitive and at runtime) are a problem too.

~~~
frowaway001
Agree. Kotlin is pretty much Java 8 with Scala syntax. It's neat, but mostly
useless.

If Google wanted to stay conservative, they could just support Java 8, but if
they wanted something considerably superior ... well, Kotlin is not
participating here.

But hey, Google sucks so much at programming languages (see Go and Dart) that
I don't expect that they do anything that makes sense for developers.

~~~
danieldk
_Agree. Kotlin is pretty much Java 8 with Scala syntax. It 's neat, but mostly
useless._

It does contain many features people have been asking for in Java for years,
but that Java 8 does not provide, such as: properties, mixins, type inference,
pattern matching, operator overloading, etc.

Also, I assume that JetBrains would be open to other features that Google
would like in a Java-replacement.

At any rate, all JVM languages, including Scala are going to be limited by the
VM and bytecode. So, you'll have to live with type erasure, without your own
value types, etc.

~~~
frowaway001
> Also, I assume that JetBrains would be open to other features > that Google
> would like in a Java-replacement.

I could totally understand that, it would probably their last and only chance
to get some users.

I don't want to sound harsh, but their situations must be quite dire right
now. The language is still stuck in some 0.x-land (unlike Ceylon), Java 8
shipped with most of their features already, they are unable to compete with
better languages (like Scala) and the tooling and IDE situation looks pretty
bad, too.

> At any rate, all JVM languages, including Scala are going to be > limited by
> the VM and bytecode. So, you'll have to live with type > erasure, without
> your own value types, etc.

Because having a VM with value types and working Generics is such an
impossible feat that no one managed to implement it? I guess not.

No one is preventing them from supporting a superset of the class file format
which allows value types and better Generics.

------
higherpurpose
Why Dart and not Go? And isn't Dart's performance more in line with Javascript
than Java? Android needs something that has better performance than Java, not
worse, but also easier to learn and use to appeal to a broader range of
developers, _especially_ new developers, that will be growing up with Android
in many countries.

~~~
grobmeier
Dart is more performant than Java says this benchmark:
[http://www.infoq.com/news/2013/05/Dart-Java-
DeltaBlue](http://www.infoq.com/news/2013/05/Dart-Java-DeltaBlue) However its
of course reasonable to ask for Golang on Android.

~~~
higherpurpose
A lot of Android developers don't like Java because of its syntax. Dart seems
_very_ similar in syntax to Java (which I assume was intentional, but the
wrong thing to do)...so not much improvement there. No wonder Dart hasn't been
getting anywhere near the excitement Go has received.

What Android needs isn't just a slightly better Java that isn't owned by
Oracle, but something more like Python that has the performance of C++, for
the next generation of developers. If they're going to deprecate Java in
Android and cause everyone a lot of grief over it anyway, they might as well
do it right, and for something truly _exciting_ to make people rally around
it.

~~~
grobmeier
Actually I think Dart has a lot of benefits in terms of syntax compared to
Java. I am working with java since 2001, so I can tell. If you are interested
to briefly look at it, you can do that here:
[https://www.dartlang.org/docs/synonyms/](https://www.dartlang.org/docs/synonyms/)

Dart makes me excited, when i am honest :-)

~~~
frowaway001
Well, comparing with Java is aiming a bit low, isn't it?

Compare Dart's "shorter alternative" of a bog-standard class ...

    
    
      // Shorter alternative
      class Person {
        String name;
    
        // parameters prefixed by 'this.' will assign to
        // instance variables automatically
        Person(this.name);
      }
    

... with something more modern:

    
    
      class Person(val name: String) // Done.

~~~
spankalee
Let's remove the comments for a more visually fair comparison:

    
    
      class Person {
        String name;
        Person(this.name);
      }
    

vs

    
    
      class Person(val name: String)
    

Ok, you save a line. I don't think that's a big deal. Also, the Dart version
is very clear about what's a field or not. The first example I found of Scala
classes on their site is this:

    
    
      class Point(xc: Int, yc: Int) {
        var x: Int = xc
        var y: Int = yc
        def move(dx: Int, dy: Int) {
          x = x + dx
          y = y + dy
        }
        override def toString(): String = "(" + x + ", " + y + ")";
      }
    

With text that says `x` and `y` are the fields. What about `xc` and `yc`, I
thought those were the fields?

Another thing I like about Dart is that the possible variations on the
constructors fall into place, consistently:

No constructor args:

    
    
      class Person {
        String name;
      }
    

Optional constructor args:

    
    
      class Person {
        String name;
        Person({this.name});
      }
    

Super call:

    
    
      class Person extends Animal {
        String name;
        Person(this.name) : super() ;
      }
    

The short Scala form may do that as well for all I know,

~~~
frowaway001
> Let's remove the comments for a more visually fair comparison:

It was not meant to be unfair, I just took an existing example. If the Dart
devs thought they needed the comments to make it clear what happens, then it's
a decision I respect.

> Ok, you save a line.

Three.

> With text that says `x` and `y` are the fields. What about `xc` and `yc`, I
> thought those were the fields?

For standard classes, the compiler just does what you tell him:

If you write that you want a "val", you get an instance value, if you write a
"var", you get an instance variable, if you write nothing (like in this case),
you will usually get ... nothing.

That's perfectly clear in my book.

> Another thing I like about Dart is that the possible variations on the
> constructors fall into place, consistently:

In most languages, allowing a constructor which forgets to initialize things
is considered a compiler/language bug.

(And having more than one constructor is pretty much considered to be an anti-
pattern in Scala anyway.)

> Super call:

In Scala:

    
    
      class Person(val name: String) extends Animal

------
theboywho
I think Swift to Obj-C is more like Scala to Java. Google should probably
bring Scala to the Android ecosystem.

------
fdsary
Why not go? Or make Dalvik handle Clojure fine?

------
BrandonSmith
Google has a problem in the form of two platforms: Chrome and Android. I
believe they will merge. Android will be Web.

\- MobileChromeApp[1] converts Chrome Apps into Android apps. Developed by
Googlers.

\- Web Components enable modular, re-usable code. Polymer[2] is backed by
Google.

\- AngularJS[3] is a modern UI framework for the Web and is backed by Google.

\- Dart[4] is a new language, with tools and libraries, for scalable Web app
engineering from Google.

\- AngularDart[5] is Angular on Dart.

\- ART[6] is a new Android runtime that leverages LLVM, opening the
possibility of offering alternative front-ends for Android other than Java.

\- Sundar Pichai runs both Chrome and Android.

\- The rumored Hera project is supposed to marry Android to the Web.

Dart + Angular + Polymer + ART = new Android Development

My bet is that the future of Android is Dart, Polymer, and AngularDart.

[1] [http://github.com/MobileChromeApps](http://github.com/MobileChromeApps)

[2] [http://www.polymer-project.org/](http://www.polymer-project.org/)

[3] [https://angularjs.org/](https://angularjs.org/)

[4] [https://www.dartlang.org/](https://www.dartlang.org/)

[5] [https://angulardart.org/](https://angulardart.org/)

[6]
[https://source.android.com/devices/tech/dalvik/art.html](https://source.android.com/devices/tech/dalvik/art.html)

------
deskamess
ART seems to be the future runtime on Android. Since it has an LLVM backend it
would be interesting to investigate LLVM IR bitcode as the "code" format used
in the apk. This would make Android development technically possible feasible
a number of languages. Microsoft has already done this with the CLR.

What I am not clear on is how this would integrate with external libraries.
Would you need LLVM IR based "shared libraries/dll's" for this to work? Google
could provide LLVM IR bitcode (.o) files for the Android platform, and the
llvm compiler/linker could reference those (this would be equivalent to the
DLL's used in the CLR). Open source apps could do the same, but I am not sure
how third party vendors feel about providing IR bitcode for their products.
The optimized LLVM IR (bitcode) would then become part of the apk.

Since ART does install time compilation, it could take the optimized LLVM IR
in the apk and generate native code for that specific device.

------
sspiff
> I like it. Even more than Java' which I used for a long, long time. Even
> more than PHP' which I used since I started with web programming. Even more
> than JavaScript, with which I am happy to work with.

Those aren't the greatest references to praise a language with. While these
three languages are obviously very popular, I thought they were widely
considered to be poor examples of language design:

* Java is extremely verbose. I wasn't aware of this when I first learned Java, as it was one of my first languages, but having recently returned after, I was surprised at how repetitive doing anything is. (Though I'm personally quite a fan of the platform design and consistency of Java, which I find very clean and intuitive.)

* JS and PHP, while both being major driving forces behind todays (and yesteryears) web, are renowned for their inconsistent design.

------
blinkingled
Golang would be sweet on Android. It'll still need to run on top of the Java
runtime but that's not too bad given that ART will be the default rather than
Dalvik.

That's not to say Java is as bad as ObjC however ;) But something less verbose
and more modern like Golang will be a great option to have.

~~~
shadowmint
Go is a great language.

...but to be fair, writing UI and graphical applications has never been it's
strong point, and still is not.

Although you can write NDK applications which steal the raw graphics context
to do whatever they like (mandala, xamarin, unity, etc.), tapping into the
android UI layer is significantly slower and more complex.

Given that the NDK website still says:

    
    
        In general, you should only use the NDK if it is essential to your 
        app—never because you simply prefer to program in C/C++.
    

I'm pretty skeptical Google is going to push anything based off of it as a
first class citizen, ever.

(That said, the upcoming I/O has what, 4 or 5 slots devoted to NDK related
things; clearly despite the android team, at least someone is paying attention
to the fact that people use it. _A lot_. So you never know~)

~~~
blinkingled
Right, but I was thinking of Golang as an optional language that you could use
to build parts of your app - the ones that require concurrency, performance
etc. and can leverage Golang's strengths. So instead of writing C/C++ you
would write Go code. You would still use Java for the UI part - that's not bad
at all - you have memory safety, maturity, Garbage Collection and some time
later even some of the cooler JDK8 features. No point in throwing all that
away.

For that usecase may be Google can extend ART to convert Go code into
something that plugs into the ART and outputs something that can be mixed with
the AOT compiled Java code.

~~~
pjmlp
I doubt it will ever happen, at least in the near future.

The ticket for Go support on Android is open since 2012 and no one from the
Android team seems to care.

The Go team has reopen the discussion of, maybe, trying to add support for it
in the 1.4 release.

------
cwyers
I don't understand (this is not a rhetorical device, I honestly don't
understand) what makes mobile development so different from desktop or server
development, where choice of OS != choice of languages. On a Linux server, I
can have Perl scripts interacting with Python scripts interacting with MySQL
stored proceedures interacting with applications written in C, and use Bash
scripts to automate the whole thing. On Windows, I can use applications
written in C, C#, Java, Python and a host of other languages, and for the most
part not care or even notice what language they were written in. Why do so
many of the new development platforms (Android/iOS/HTML5) embrace this "one or
two languages" paradigm?

~~~
pjmlp
It is no different from the desktop, actually.

Just go look what were the official programming languages from the OS vendors,
along the computing history.

What you have lacking is that nowadays, thanks to opensource, outside OS
vendors, companies see little value investing into compiler development.

So very few companies produce compilers the mobile OS.

As a result you are left with the open source community, with very few
resources tackling these issues.

This all leads to the situation, where the only production quality compilers
are the official ones.

------
aikah
Dart is a great idea!

About the other languages/plateforms :

Scala/Clojure/Kotlin... already work on the JVM...so they work on Android.

Go is nice.But devs want explicit classes, generics, ... go has no generics.

ChromeOS :a wide range devs dont want to deal with web techs,and neither WebOS
or FirefoxOS has proven they are a successfull plateform.Android definetly is.

But I dont see google replacing all the toolchain the JVM provides anytime
soon.The only thing they could do is design a language that runs on it and
provides the tooling for that.Now can Dart run on the JVM?

------
norswap
I'd like to see some comments on how Java falls short. I always felt that it
had an undeserved bad rap. One way in which it was _very_ bad is terseness -
but that's getting much better today with better type inferencing and lambdas.

~~~
eloisant
It is getting better indeed, but there are still features lacking that force
you to write code that is much more complex that if you had them.

~~~
norswap
Such as? (Not doubting, merely interested.)

------
octopus
Probably the best move for Google would be to write a super fast WebView
implementation. This will let the huge mass of web developers to use
JavaScript at a speed comparable to Java.

------
rcarmo
In terms of priorities, I'd think replacing JavaScript with Lua on the browser
would rank higher -- it would at least make a lot more developers far happier.

------
otikik
I am ok with this as long as they give us golang on android first.

------
dscrd
Or perhaps Google should bring ChromeOS to cell phones and deprecate Android.

~~~
jacquesm
It would be complete insanity from a branding perspective to take an absolute
blockbuster brand like Android and to deprecate it in favour of ChromeOS which
hardly anybody has even heard of outside the tech scene. Android has a name
recognition on par with some of the biggest brands out there.

~~~
dscrd
Branding and marketing are a minor detail, and almost completely decoupled
from technical issues. They could figure out something clever... or something
simple like calling it Android 5.

