IMHO, I'm not sure if any of the above there besides the testing libraries is something that should be part of Kotlin, _especially_ if it hasn't even yet hit v1.0.

That having been said, I think your concerns will be addressed, _eventually_, but JetBrain is not trying to disrupt Java or its ecosystem before mainstream adoption of the language.

Re: async capabilities like Erlang/Go, until the JVM can support continuations, an industry standard solution like bytecode instrumentation, which Java9 will improve on, will entrench libraries like Quasar / RxKotlin to be basically drop in. These libraries provide seamless interoperability with existing synchronous libraries (see https://github.com/puniverse/comsat) to get around the fact that Erlang's/Go's async capabilities are not built-in to the language.

There is Quasar if you want Go or Erlang style concurrency in either Java or Kotlin (and the Pulsar wrapper to it for Clojure).

No reason to bake it into the language -- and as you can see from comparing the Java and Kotlin sample code, there is a reason for a language that let you write Groovy-like DSLs.

http://docs.paralleluniverse.co/quasar/

>> No reason to bake it into the language

Go-style channels and goroutines are built on green threads which Go/Erlang has, but the JVM does not have. One way to work around this is to use fibers and continuations which is what Quasar is doing.

For tests : I have had some nice experience writing jUnit tests with pitest (PIT) : there is a gradle plugin to do that in AS/Idea

The only issue I had was to ignore Package class to make pit work

For DI, Dagger2 works fine with kotlin

For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)

> For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)

Have you opened up an issue on Quasar's repo (https://github.com/puniverse/quasar) so Parallel Universe can track this for a possible milestone?

We don't need to : I read somewhere that it was on their roadmap...

If you want easy multithreading on Android take a look at Kovenant http://kovenant.komponents.nl/android/features/

Can you use PIT with Kotlin? Really tempted to try it out but wasn't sure. I suppose if it works at the bytecode instead of source level it would just work.

Yes you can (I managed it and it works beautifully). But you have to make it ignore Package Class at the moment because top functions in a package (say my.great.pack) can be in different .kt files and are gathered in a single class (my.great.pack.PackPackage) and pit doesn't seem to be able to cope with a class whose source come from more than 1 file (or I missed something).

Just put something like this in your gradle.build file :

apply plugin: "info.solidsoft.pitest"

pitest { targetClasses = ['org.lakedaemon.suggest.', 'org.lakedaemon.compress.'] //by default "${project.group}." excludedClasses = ['org.lakedaemon.compress.decoders.DecodersPackage', 'org.lakedaemon.compress.decoders.EncodersPackage'] avoidCallsTo = ['org.apache.log4j.', 'org.lakedaemon.L.', 'org.slf4j.', 'java.util.logging.'] pitestVersion = "1.1.4" //not needed when a default PIT version should be used threads = 4 outputFormats = ['XML', 'HTML'] enableDefaultIncrementalAnalysis = true testSourceSets = [sourceSets.test/, sourceSets.integrationTest/] mainSourceSets = [sourceSets.main/, sourceSets.additionalMain*/] }

> Currently it sucks to write tests with JUnit while using Kotlin

Why?

> XML based Build Tool, I mean seriously? It should at least be somehow human readable.

It's entirely human readable in my subjective opinion. At the very least, it's as human readable as HTML...

> A language should need a sane integration of it, not the library itself.

Any language which has constructors already has the best DI integration available.