What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange.
Also I still miss a good build tool. I mean Maven really sucks, Gradle is kind of okai, but there is no support of autoreload project on change (like sbt has via sbt-revolver or playframework internals) however that is mostly helping web development.
Also some other things aren't really written out, like threading or some kind of Akka stuff. Also these days a language needs Dependency Injection, a good Integration with JSR330 would be great.
Also for some functional workflows something like pattern matching would be great and a @tailrec annotation like scala.
And please, for gods sake, remove labels and break/while.
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.
> Beyond that, we used to find ourselves in dependency hell with maven pretty frequently
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.
> Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day
"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.
I think that calling something verbose and unreadable is an oxymoron. XML is very explicit about what each field is labeled. Having an XSD means you always know what field is available where and what type of values are permitted. BUT, if you're still not happy, there's always polyglot maven[1]
Why why why do do do you you you think think think that that that a a a language language language that that that was was was verbose verbose verbose could could could not not not also also also be be be unreadable unreadable unreadable ?<question> ?<question> ?<question>
> I think that calling something verbose and unreadable is an oxymoron.
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.
Indeed, but it could be argued that excess verbosity might be better for long-term maintainability. Not that I'm defending the topic at hand here: XML as a configuration language.
Interesting you say that because I feel that XML is a bit oxymoronic a priori. They wanted something both human and machine readable, but fails to be great at either.
Currently it sucks to write tests with JUnit while using Kotlin, there is Spek (Jetbrains made it(, but it's early (too early).
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.
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.
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.
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*/]
}
Also I still miss a good build tool. I mean Maven really sucks, Gradle is kind of okai, but there is no support of autoreload project on change (like sbt has via sbt-revolver or playframework internals) however that is mostly helping web development.
Also some other things aren't really written out, like threading or some kind of Akka stuff. Also these days a language needs Dependency Injection, a good Integration with JSR330 would be great.
Also for some functional workflows something like pattern matching would be great and a @tailrec annotation like scala.
And please, for gods sake, remove labels and break/while.