Lorefnon

Open Web Enthusiast

Apr 6, 2017

Strictly speaking, Kotlin is not intended to be an evolution over any of these languages. It's true intent is to be an evolution over Java (and javascript) while being seamlessly compatible, and given the massive adoption of these languages it is a very pragmatic objective.

It is however, comparable to all of these because it directly competes with them across realms ie. JVM, Javascript (except Groovy) and even native (only scala).

Kotlin is a lot more focussed than Scala, which IMHO is practically a kitchen sink of academic ideas. Unlike attempting to reinvent how you would program, or giving you an overwhelming array of paradigms to pick and choose from, Kotlin identifies and fixes the pain points that plague java development: null pointer exceptions, explicit casts, generics with no type safety whatsoever, verbose beans etc.

It is opinionated in the sense that it assumes that the programmer is happy with object oriented development and brings in proven ideas from other paradigm (like pattern matching, lambdas, co-routines) conservatively to enrich the developer experience and solve problems (esp. concurrency) where traditional strategies have proven ineffective.

This is great because you neither end up with an anaemic featureset (eg. Golang) nor a multiverse of competing paradigms in the same language (eg. Scala, C++).

Conservatively including features implies the compiler authors can keep compilation times under check, ensure errors are sensible and it is easy to work through into a new codebase (compiling a large Scala project, or C++ project that heavily uses templates takes forever, Complex C++ templates result in horrendous compilation errors when things go wrong etc.).

And of course, this is a product coming from Jetbrains - who are probably among the most competent professionals working on language tooling.

Clojure and groovy are dynamic languages. JVM has evolved into a great platform for dynamic languages, and that is a great thing. But here we have a team which is way more focussed on tooling as opposed to facilitating the paramount flexibility of lisp world. It is only natural that they invest into a language that is designed to facilitate sophisticated tooling.

Many things that make Clojure great (homoiconicity, metaprogramming etc.) are simply not in radar of kotlin developers because they make assistive tooling incredibly hard.

It is not a coincidence that there is simply no tool in existence that can do complex automated refactorings for languages like ruby or clojure, in the same way Java IDEs have been doing for years.

Having said that, Kotlin does recognize that dynamic programming languages offer a level of productivity that is usually not found in compiled languages - and it does bring in some nice features from these languages vis. Groovy like DSLs, an REPL. Decent type-inference and smart casts alleviate much of the redundant boilerplate which is so common in java projects.

In an ideal world type systems will grow flexible enough to facilitate the same level of succinctness and flexibility as dynamic languages but languages like Scala clearly demonstrate that it is not an easy task and some really interesting problems and a steep learning curve hinders us from getting to that point just yet.

I strongly believe that compiler authors and language developers will keep working in this direction and this is evidenced in newer languages like Crystal which brings to the table an interesting approach towards transparent type safety .

For the rest of us, who need to get stuff done today, Kotlin aims to find a sweet spot in between overwhelmingly flexible dynamic languages like lisp and arcane languages with complex type systems, as well as between everything-should-be-a-class object oriented paradigm and side-effects-are-pure-evil functional paradigm.

And in that respect, it seems to have done a much better job than other mainstream languages eg. Java, C# and Javascript.

P.S. I am a full time javascript developer and have done most of my programming using dynamic languages.

P.S. I am also not claiming that Kotlin language tooling is at par with java tooling yet, but I do believe it has the potentially to be so.

Sai Kishore Komanduri

Engineering an eGovernance Product | Hashnode Alumnus | I love pixel art

Apr 7, 2017

Wow, that is a wonderful answer, I must say! :) I'm curious, could you elaborate on what you mean by 'golang ending up with an anaemic feature set'?

Thank you.

I didn't (want to) spend much ink criticising golang because my exposure to golang is fairly limited - I just haven't found much that motivates me to explore this language deeper.

It has some good ideas, like programming to interfaces but it is fairly limited in facilitating elegant abstractions over complex functionality and that is by design.

For instance, Kotlin's builders allow you develop domain specific languages tailored to use cases. F# computations expressions are even more sophisticated in that they allow programmers to intercept the control flow of a part of program and facilitate transparent asynchronous programming, logging etc.

The examples in the posts above do not rely on special blessed language features defined by compiler, but are defined by userland libraries. Having a powerful language core allows libraries to facilitate a lot of powerful abstractions which are, in practice, indistinguishable from core language features.

A great advantage of this kind of approach is that when you are reading someone else's code you can focus on the happy path, and dig into the corner cases, error handling etc. only if you really need to.

Such kind of abstractions are simply impossible in Golang because of it's strong focus on 'being explicit' and 'closer to metal'. It may be an advantage if you consider the primary use case to be low level systems programming language, but as alternatives like Rust have demonstrated, low level systems languages can be surprisingly expressive.

Things like pattern matching, computation expressions, destructuring are all wonderful examples of how high level language features can facilitate sophisticated abstractions, and Go happily eschews them all.

Null safety also does not seem to be anywhere in golang's priority list. Error handling support is bleak. I am not saying that java-esque exception handling is the single best approach towards error handling, but just that of the alternatives available the multi-return convention is perhaps the most error prone (pun intended).

To be very frank, for building high level applications, where you can afford to invest in infrastructure and a moderate learning curve, Golang is seldom the best choice.

Search Hashnode