5 ms·

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 applica

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.)

tutanchamun 10y ago
What functinal techniques did you use? Only higher order functions or did you go all the way to applicatives, monads (maybe even free) etc.? btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.
- meddlepal 10y ago
  I'm interested in the comparison code as well if it's available.
Scarbutt 10y ago
Curious, if you were aiming at writing in a functional programming style, why didn't you try Clojure?
- yawz 10y ago
  If I may jump in, here, for my 2 cents, I've never developed anything commercial with Closure, but I learned it, have played with it and have quite enjoyed it. Having never done any Lisp(-based language) programming before it didn't come... naturally. My guess is that the parent commentator didn't include it for that reason.
- tormeh 10y ago
  It doesn't have compile-time type checking. When many people say functional code they really mean code that can be and is strictly type checked at compile time. Clojure is functional, but it's not what most people want when they say "functional".
  - mlmlmasd 10y ago
    Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.
    - Sammi 10y ago
      It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :) I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.
      - mlmlmasd 10y ago
        Static typing is great. My point is that whether a language is statically or dynamically typed has no bearing on whether it is functional.
ditn 10y ago
>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. https://github.com/mockito/mockito/wiki/What's-new-in-Mockito-2#unmockable https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...
brianwawok 10y ago
> 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.
vorg 10y ago
> 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.

tutanchamun 10y ago

What functinal techniques did you use? Only higher order functions or did you go all the way to applicatives, monads (maybe even free) etc.? btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.

meddlepal 10y ago
I'm interested in the comparison code as well if it's available.

Scarbutt 10y ago

Curious, if you were aiming at writing in a functional programming style, why didn't you try Clojure?

yawz 10y ago
If I may jump in, here, for my 2 cents, I've never developed anything commercial with Closure, but I learned it, have played with it and have quite enjoyed it. Having never done any Lisp(-based language) programming before it didn't come... naturally. My guess is that the parent commentator didn't include it for that reason.
tormeh 10y ago
It doesn't have compile-time type checking. When many people say functional code they really mean code that can be and is strictly type checked at compile time. Clojure is functional, but it's not what most people want when they say "functional".
- mlmlmasd 10y ago
  Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.
  - Sammi 10y ago
    It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :) I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.
    - mlmlmasd 10y ago
      Static typing is great. My point is that whether a language is statically or dynamically typed has no bearing on whether it is functional.

ditn 10y ago

>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. https://github.com/mockito/mockito/wiki/What's-new-in-Mockito-2#unmockable https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...

brianwawok 10y ago

> 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.

vorg 10y ago

> 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.