pkuki

Also for GGO 2012 you can view entrants here: http://pkukielka.github.io/ggo12-viewer/ (disclaimer: viewer was done by me). If I remember correctly someone forked my code and did the same for 2013 edition.

Look at the original blog post. I just added third column to show ratio between given data.

I thought it could be interesting to see ratio of program performance to its length. If I didn't make any mistake it looks like that:

              perf3                   perf3 / 
              macros      chars       chars * 100
  -------------------------------------------------
  scala       15963       24885       64,15
  nim         11121       20263       54,88
  java        17969       53223       33,76
  ocaml       7063        24371       28,98
  coffee      2326        15653       14,86
  racket      2461        17229       14,28
  cs          5414        45039       12,02
  clojure     1174        10099       11,62
  ruby        1255        13247       9,47
  go          3048        36321       8,39
  vb          4523        58099       7,78
  rust        4084        56516       7,23
  js          1726        26437       6,53
  c           3649        73047       5,00
  haskell     1163        30115       3,86
  python      304         19632       1,55
  forth       563         44715       1,26
  php         331         27332       1,21

Down in Poland as well.

It's simply incorrect. Where you found that information?

In section 2.3 android is mentioned explicitly: "These features are more useful on Android (besides micro-benchmarks) where a vast RAM doesn't masquerade redundant allocations."

In section 5.2 you can read: "This prototype requires -target:jvm-1.7. Right now scalac doesn't produce the newest class file format of JDK8. In the meantime, -target:jvm-1.7 can be used on that platform. A discussion about performance at: https://groups.google.com/d/msg/scala-internals/uBxprJixpwk/...

If you will check that link first sentence in the thread is: "To recap, the new backend supports Java 6 and 7. In an experimental branch (based itself on the experimental backend) there's now support for MethodHandles, building upon "Late Closure Classes", ie the ability of the new backend to materialize anonymous closure classes as it emits bytecode."

So yes, it supports java 1.7. And yes, it can help on android.

In Akka you can use typed actors as well: http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.htm...

You can also use Scala: https://github.com/pkukielka/stronghold-defense

The main problem which you will get with languages like Scala , Clojure and other functional languages on JVM is a lot of garbage generated during the execution. And garbage collector on Android isn't even remotely as effective as standard one. This often forces you to write code which is not really idiomatic and which rather resembles java. That is possible in Scala (I'm not sure about Clojure), but to some extend it defeats whole purpose of using something other than java.

Disclaimer: I'm the author of linked game.

Maybe they are slower to some extend, but for most cases it won't matter too much. I wrote simple game in scala and it was easy to constantly get 55-60 fps on newer devices: https://github.com/pkukielka/stronghold-defense

That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android.

So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.