Why?

I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years.

The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I've written a maven plugin, and the documentation/support was rather poor. I also found myself having to use an older version of various plugin libraries in order to write proper tests for the plugin. It took me a couple of weeks. Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day.

That said, it's stable and well known. Gradle seems to have the momentum and increasing mindshare, but you probably won't get fired for using maven.

You'll hit that with Gradle, Ivy, Leiningen, SBT and Buildr too.

> The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I'd also call that it's biggest strength. Maven POMs are only ever declarative. I've never hit a FOSS project using Maven that I couldn't build, but I've hit plenty using SBT or Ant that I had to tweak to build.

> I've written a maven plugin, and the documentation/support was rather poor.

I had the same experience with Gradle's DSL documentation, although having a look at it now, they've dramatically improved it since then.

"Probably"? "Thrown in"? Perhaps you can cut and paste build scripts between Gradle projects, but write anything more than "a few lines" in Groovy and you're looking at huge maintenance problems, like something that evaluated as ["abc", "defg", "hij"] suddenly becoming ['a', 'b', 'c'] for reasons that become apparent only after hours of printing debug messages.

[1] https://github.com/takari/polyglot-maven

Weird.

Verbose and unreadable are not contradictory descriptions. In fact, they are more complementary descriptions -- there is a reason that in natural languages one of the most frequent recommendations for clear and readable writing is to be concise.

Excess verbosity is bad for readability.

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

A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable.

I mean good Multithreading lives in RxKotlin which is based on RxJava, however I still think that Threading or some kind of Library which should handle mutli prozessors / async capabilities should live INSIDE the language (like go, erlang or lots of others).

I mean currently Java9 will get a lot of new things which will definitely help out Scala to compile faster and Java10 will bring these closer. So there is no real reason for a language that still lacks a lot of stuff. As already said, Kotlin is small, on some edges thats good, on some it's just too small and I don't get it why they built while, break and continue into a somewhat functional language. Especially when while, break and continue is really hard to handle / read.

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.

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/

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.

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)

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?

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*/] }

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.