A few weeks ago I wrote the same application four times in four different JVM languages: Java, Groovy, Scala, and Kotlin, with a particular focus on the application using functional techniques and types as well as being reactive. I also included as goals complete test coverage with a preferred test framework from each language and complete build tooling, all within a single Gradle project.
The only significant sources of variance were the following:
a) Groovy's support for functional programming is starting to show its age. It worked with everything, though.
b) The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck, but { val x = expr; x.method() } does. (All three pass IntelliJ's typechecker for Scala.) Outside of this (aggravating) issue and slower build times, it did work.
c) Java works well with everything but ends up being quite verbose, especially in regards to a functional programming style (no surprise there).
d) Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.
Based on my experience with all four languages, I would definitely try adding Kotlin to projects. It seems to be surprisingly mature and stable given how much less time it has spent in development (relative to the other three languages.)
>Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.
It's worth pointing out that since Mockito 2.0, you've been able to opt into mocking final classes, making testing Kotlin pretty painless.
> The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck
There are many many things that should be valid Scala but are not, due to type check limitation. All kinds of times you should be able to infer the type, but the compiler cannot and you have to start naming types. Not sure this is really a "bug" but more of a wart. Sure is annoying when they happen, but not a "unique" thing to Java8 lambdas by any measure.
> all within a single Gradle project. [...] Groovy [...] worked with everything, though.
Given that Gradle was originally designed with Apache Groovy as its only language for writing its build config files, I'd say you should try again with the build system relevant to each language, such as SBT for Scala, Leiningen for Clojure, etc.
Kotlin for me is Java made right. It's not complex, it has awesome interoperability with Java, it uses JDK, not reinventing its own wheels and it has everything I need from modern language.
But it seems that Jetbrains has its own vision for Kotlin being a completely independent language. So while it works for me right now, I'm not sure if it will work in the future. They are going native and it'll bring a lot of changes, for sure. Honestly I would prefer it to stay as Java enhancer, as I'm not interested in Native and I need very little JavaScript interoperability, if any (probably just translating some common code between backend and frontend).
But we will see, I don't want to sound too pessimistic. Kotlin is the best language I've used so far.
Even with Kotlin Native in mind, we have no plans to break Kotlin's backwards compatibility guarantees, and we do plan to support the new JVM features such as value types. So if Kotlin works well as a Java enhancer for you today, it will only work better in that role in the future.
Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.
I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.
My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.
And the fact that it has a rather small standard library with JVM 6 compatibility means it's very very easy to adopt it into existing Java 6 (Android!) projects.
There are many languages for backends and tons of libraries. But there is hardly any substitute of Java in Android(if you don't consider JS solving every problem in this planet). If JetBrains only concentrate on building an ecosystem for android, it can become "the real Swift for android".
I built a dummy app for android in Kotlin. It was great. The same thing I tried in Scala(it didn't go very well).
What I like about Kotlin is it's what you might call a "pragmatic Scala", and could find a sweet spot between Java and Scala where its added expressiveness allows it to shine, but Scala's complexity and performance issues aren't in evidence to scare the development managers into staying with Java.
How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
> How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
JavaScript backend generates code understandable by static analyzers so it can be optimized.
Anyway, we going to continue works in this area in near future.
> Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Why do you think that reflection is a bad idea?
Honestly, we don't have a final decision about it, it requires investigations and discussions.
Note it's very important for us to have an ability to provide good tools (e.g IDE support) for features.
> Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
I wouldn't touch Java if I could write something in Kotlin instead. I'm using Swift on a daily base and while it still has it's issues (compile times, breaking changes) it's a great language to work in and extremely similar to Kotlin.
The post specifically mentions using Kotlin Javascript to develop React applications. Are there any simple examples out there showing this? I'm not seeing any after a quick google search and look through the docs.
Developing a modern frontend app is complex enough with Javascript or Typescript. It's pretty hard to ask people to figure it out from scratch in Kotlin by just saying that it's possible but not showing how.
It was mentioned on the Kotlin slack that Jetbrains would make some examples available within a few weeks on using Kotlin JS including using it with React.
I don't think of 'func' as a standard. Off the top of my head, you can see "defun", "fn", "def", "function", and on and on in various languages. I don't see much agreement across the board.
[+] [-] WkndTriathlete|9 years ago|reply
The only significant sources of variance were the following:
a) Groovy's support for functional programming is starting to show its age. It worked with everything, though.
b) The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck, but { val x = expr; x.method() } does. (All three pass IntelliJ's typechecker for Scala.) Outside of this (aggravating) issue and slower build times, it did work.
c) Java works well with everything but ends up being quite verbose, especially in regards to a functional programming style (no surprise there).
d) Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.
Based on my experience with all four languages, I would definitely try adding Kotlin to projects. It seems to be surprisingly mature and stable given how much less time it has spent in development (relative to the other three languages.)
[+] [-] ditn|9 years ago|reply
It's worth pointing out that since Mockito 2.0, you've been able to opt into mocking final classes, making testing Kotlin pretty painless.
https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...
[+] [-] Scarbutt|9 years ago|reply
[+] [-] tutanchamun|9 years ago|reply
btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.
[+] [-] brianwawok|9 years ago|reply
There are many many things that should be valid Scala but are not, due to type check limitation. All kinds of times you should be able to infer the type, but the compiler cannot and you have to start naming types. Not sure this is really a "bug" but more of a wart. Sure is annoying when they happen, but not a "unique" thing to Java8 lambdas by any measure.
[+] [-] vorg|9 years ago|reply
Given that Gradle was originally designed with Apache Groovy as its only language for writing its build config files, I'd say you should try again with the build system relevant to each language, such as SBT for Scala, Leiningen for Clojure, etc.
[+] [-] vbezhenar|9 years ago|reply
But it seems that Jetbrains has its own vision for Kotlin being a completely independent language. So while it works for me right now, I'm not sure if it will work in the future. They are going native and it'll bring a lot of changes, for sure. Honestly I would prefer it to stay as Java enhancer, as I'm not interested in Native and I need very little JavaScript interoperability, if any (probably just translating some common code between backend and frontend).
But we will see, I don't want to sound too pessimistic. Kotlin is the best language I've used so far.
[+] [-] yole|9 years ago|reply
[+] [-] afastow|9 years ago|reply
Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.
I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.
My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.
[+] [-] pswenson|9 years ago|reply
We've seen 1/10 the memory usage on golang vs java with similar performance, so properly executed there is a big opportunity in the native space.
[+] [-] izacus|9 years ago|reply
[+] [-] sandGorgon|9 years ago|reply
Kotlin is getting first class support on next generation Spring web framework with functional programming support - https://speakerdeck.com/sdeleuze/functional-web-applications...
it's almost done with first class support for vert.x which is a high-performance reactive webframework https://github.com/vert-x3/vertx-kotlin-common
The reactor project (erlang for the jvm?) is building first class support for kotlin https://github.com/reactor
I think its going to be a great year for building backend systems on jvm.
[+] [-] asitdhal|9 years ago|reply
There are many languages for backends and tons of libraries. But there is hardly any substitute of Java in Android(if you don't consider JS solving every problem in this planet). If JetBrains only concentrate on building an ecosystem for android, it can become "the real Swift for android".
I built a dummy app for android in Kotlin. It was great. The same thing I tried in Scala(it didn't go very well).
[+] [-] grabcocque|9 years ago|reply
[+] [-] Scarbutt|9 years ago|reply
Is Kotlin really faster than Scala?
[+] [-] mwcampbell|9 years ago|reply
http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
I have a few concerns about Kotlin's JS backend:
How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
[+] [-] bashor_|9 years ago|reply
JavaScript backend generates code understandable by static analyzers so it can be optimized. Anyway, we going to continue works in this area in near future.
> Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Why do you think that reflection is a bad idea? Honestly, we don't have a final decision about it, it requires investigations and discussions. Note it's very important for us to have an ability to provide good tools (e.g IDE support) for features.
> Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
We will work on it.
[+] [-] danneu|9 years ago|reply
I think Kotlin is the statically-typed language I've been waiting for, especially with the team's interest in native and JS targets.
[+] [-] Scarbutt|9 years ago|reply
[+] [-] dep_b|9 years ago|reply
Better type safety means less crashes.
[+] [-] meddlepal|9 years ago|reply
Definitely excited. It's an awesome JVM language.
[+] [-] agumonkey|9 years ago|reply
[+] [-] sandGorgon|9 years ago|reply
[+] [-] afastow|9 years ago|reply
Developing a modern frontend app is complex enough with Javascript or Typescript. It's pretty hard to ask people to figure it out from scratch in Kotlin by just saying that it's possible but not showing how.
[+] [-] Teedee753|9 years ago|reply
[+] [-] netcraft|9 years ago|reply
[+] [-] curyous|9 years ago|reply
[+] [-] richard_todd|9 years ago|reply
[+] [-] dalailambda|9 years ago|reply
[+] [-] cdelsolar|9 years ago|reply
[+] [-] jbmorgado|9 years ago|reply
[+] [-] bashor_|9 years ago|reply