Reading Why you should totally switch to Kotlin

I don't believe in titles like Why you should totally switch to Kotlin or Ten Reasons Why I Don't Like Golang (subtitle: why “I wouldn’t use it for a new project”), but being curious about languages, I always like to read this kind of articles, and eventually criticise them — though I neither advocate for nor oppose to any language in particular.

So…

Java Interoperability

Kotlin is 100% interoperable with Java.

As you expect from every JVM based language, even if maybe this isn't so sure. However, Scala is interoperable. So, why Kotlin and not Scala?

Familiar Syntax

What is familiar depends on people's experience, which in turn depends on job demands, which can be very biased for a reason or another.

If universities continue spitting OO “imperative programmers” of curly bracket family languages, and if self-taught programmers learn just what they think can make them hired (and employers may hire according to what's the buzz but without clues on what they really need), then anything going off-path won't look familiar.

But it doesn't mean it is a good thing. Sometimes an unfamiliar syntax and/or paradigm, unused just because it isn't how everybody else is doing things, can express ideas better and help doing better programs.

String interpolation

C# has it. Other languages, and again I have to cite Scala, have it. Also many of the dynamic languages like Perl, Ruby, and Python3, have it. Groovy, another language targeting JVM, has it. It isn't anything that would make me pick Kotlin instead of, say, Scala…

Type inference

If you are grown up associating strongly typed languages with the need to explicitly tell to the compiler the type of each variable, then type inference is a magic bullet that saves you from this annoying burden. Type inference is common in many “modern” (i.e. recent) languages.

Of course Scala, another language which targets JVM, has type inference too. So, Scala or Kotlin?

Smart casts

Kotlin is watching you! Interesting, though auto-casting scares me a little. Kotlin tracks me, but I need also to track my logic's correctness…

Intuitive equals

What if a == b were just syntactic sugar for a.equals(b)? It reminds me other languages…

Default arguments

Scala has them too. Groovy too. (C++ too… and many more…)

So, again, Scala or Kotlin?

Named arguments

Guess! This isn't, again, a Kotlin speciality. So the article is telling us just that Java sucks, a little bit, but not that Kotlin beats all the challengers.

The when expression

Why is it much more readable? I can't see the much more.

About flexibility, I agree… but you can smell pattern matching; Scala's match is very powerful and flexible too, and it can be used as an expression too…

Properties

That's an idea. Which isn't new, of course. But Java hasn't properties.

Here languages like C#, Sather, and Groovy can teach something. And Scala, again… Scala follows the uniform access principle, like Sather,

The data class

Sometimes we need just data structures. Don't we need behaviours too? Don't we need to act on those data someway? In this post a data class is treated as code smells/dispensable: A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand..

I am not sure I totally agree with them, nonetheless…

Kotlin gives a special “construct”, data class, hence promoting data classes to a valuable figure. But we have toString(), equals() (or the intuitive equals ==…), hashCode(), copy(), componentN()…

So, maybe…

Operator overloading

This gives a sense of power, but many are scared by the fact that a + can have meanings beyond those the symbol usually has.

Anyway, Scala can, too. (Even if operators are syntactic sugar, but this is an irrelevant detail.)

Destructuring Declarations

After all, ideas flow and you find them around in different languages (but not all, because people sometimes disagree on what it's worth).

Among languages targeting JVM, Groovy has object destructuring with multiple assignment. I don't know if this covers all the power of Kotlin, but…

Ranges

Java hasn't a way to express ranges? Java is primitive…

Ranges are common in many languages, though the syntax varies. Scala has ranges, too (you write 1 to 100 instead of Kotlin's 1..100). Groovy's ranges are syntactically closer to Kotlin's ranges (closer, not equal: in Groovy you write (2..10).step(2), in Kotlin 2..10 step 2…).

Extension Functions

This is a feature that I always expected by OO languages. First I've seen it in Objective-C and Smalltalk. Anyway, Java hasn't it — what a shame. Kotlin fills this gap.

Null Safety

Groovy has the safe navigation operator too: ?. (same syntax), and the Elvis operator (?:), too. So the example in Kotlin can be translated into

def name = ship?.captain?.name ?: "unknown"

Kotlin offers a little bit more and a safety net at compilation time. Mind your nullable vars!

Better Lambdas

Maybe it isn't Kotlin which has better lambdas: it's Java which took them wrong, becoming the worst!

Jokes apart, Java's syntax for anonymous lambda isn't bad, but it feels so wrong when you want to assign your lambda to a symbol, like sum in the Kotlin's example.

You need functional interfaces, which are tedious and syntactically ugly.

interface IntOp { int op(int a, int b); }
//...
IntOp sum = (x, y) -> x + y;

But then you must use it like sum.op(1, 2). java.util.function has several predefined interfaces. Terrible to be used. And I've also discovered that “templates” can't use primitive types; so

interface MyOp<A, B, R> { R op(A a, B b); }

forces us to use Integer instead of int.

Here Java took the wrong path. And C++ has them better, too! ;-)

IDE support

its features demonstrate the advantage of having the same people design both language and IDE.

I don't think it's a requirement to have good IDE. And, bet it, they try to promote Kotlin, so they have a tool to convert Java to Kotlin. And they can recognise cut-pasted Java code… Is this awesome in the machine learning era, or it's a trivial task?

Conclusion

As usual with this kind of articles, few points are really interesting. The others are a matter of taste, or just things which doesn't drive every programmer towards Kotlin (or away from Go Java…)

To me Kotlin learned its lessons from other languages, Groovy and Scala included. Nothing really original, but maybe it's a sane combination of features which otherwise weren't altogether.

I imagine that in a future world where Kotlin is used as Java EE, we will blame the Java interoperability that brought us the whole sick bundle of frameworks Java has.