June 20, 2016

Mini Golang Rant and Kotlin Kata

It's been a while since I have been able to focus on my never-ending slowly progressing Kubernetes PaaS project Sitepod, once again demanding paid work around e-commerce and Node.js consumed me for the last several months, that's easing up now.

Large parts of Sitepod have been built in Golang, and whilst this has stagnated against Kubernetes 1.4 and its limitations it could be reshaped, but now I am reluctant to continue any further with Golang. And yes, this is heavily due to lack of generics, gopher hipsters say "you don't need the g word, you're doing it wrong" resulting in code like this or the use of go generate or whatever new macro variants in later versions. Also, the lack of language sugar is extremely productivity denting, sure I don't need a thousand ways to do things, but the absence of even basic sugar makes it feel as restrictive as C# 1.1 at times. I don't buy the simplicity argument here, hopefully, Golang 2 will rectify all this as I do like gofmt and the simple build chain.

I digress, so whilst I am writing parts of Sitepod in Clojure now, I'd also like to simultaneously bring up a version (or at least a Kubernetes client) in a strongly typed language, on the radar has been F# (with dotnet core and native compilation), OCaml (against Batteries) and after the announcement at Google I/O 2017 Kotlin v1.1.

Kotlin has an appealing ecosystem in comparison to the other candidates partly due to:

  • JetBrains employees 40 full-time people devoted to the language, compared with Microsoft which currently employs only one person dedicated to F#, and OCaml where much is done via research grants or via JaneStreet and has about a much predictability as AngularJS in release schedules (is multi-core even done yet?). Support wise Kotlin appears to be the safest bet.

Language development will continue to be sponsored by JetBrains, and the Kotlin team (over 40 people and second largest team at the company) will operate as usual.

  • Jetbrains and Google are actively moving Kotlin to a foundation. This ensures JetBrains don't have too much control or abandon the project whilst holding on to the trademarks, community resources and IP. This is great as other communities have demonstrated, for example, there's much bitterness towards Cognitect Inc due to the full dictatorial control they exercise on Clojure.
  • Kotlin targets JVM, Native, and Javascript. F# Javascript target is done by Fable, a third party compiler, same with OCaml where multiple javascript compilers exist. Javascript should be a first class target of any modern language in my opinion.
  • I might not develop Android apps now or in the future, but having 500k Android developers potentially adopting Kotlin is amazing for building the community, growing support resources, and providing feedback to drive the tools and language forward. I just can't see F# via Xamarin having the same effect, given neither Google or Apple actively champion it on their respective platforms.
  • First class free IDE with debugging in IntelliJ community edition. Although I did the following kata with just vim, an IDE is likely to increase productivity, at least until we have compiler services and better plugins. Will @k_cieslak create a vscode version? There are ambiguous hints.

All sounds inviting but with no Kotlin coding experience I needed to test the waters. I decided to port this Tennis scoring kata from F# to Kotlin. The code is available on my Github, also do take a look at Vaskir's refactorings in Issue#1 which brings some cleaner formatting and using apply { } etc...

So far so good, definitely worthy of more exploring, expressivity close to F#/OCaml, easier to read, easier to get going (less than two afternoons with Kotlin), but it's not without flaws, even on this primitive example I noted a few things:

  • Pattern matching is much stronger in F# and OCaml. Pattern matching feels more like a Golang type switch and with such limitations. Perhaps unfair given this was a F# kata originally.
  • Gradle, yet another build system with its own DSL. Not much pain for basics but still a heavy amount of scaffolding to compared to say Node.js (but you get to install node/npm to use yeoman to generate the build files, no shit)
  • The distinction between list and lazy sequences. Apparently, there are good theory ideas behind this but I like Clojure's approach better, also no chunking on lazy seq as far I can see. asSequence() converts lists to sequences - although nostalgically it reminds me (in reverse) of C# devs who struggled with LINQ's lazyiness and put .ToList() everywhere. Perhaps future enlightenment awaits on this point, I do hope.
  • Incremental compilation is nice and fast. And the strong type system behaved the same way as F#/Ocaml in making many errors compilation errors, it still couldn't stop me from screwing up the rules of tennis even on a porting exercise, no type system is that great.

Before I attempt a rich Kubernetes client in Kotlin - one on parity with golang that includes informers, work queues etc.., not just some swagger generated api - I need to play more with Kotlin, test out async functionality, locking primitives, immutable data structures. In meantime I continue to work on a Clojure version, when I'm up to speed in Kotlin I'll consider the practicality of developing both versions at the same time (in expressive languages coding isn't really the biggest timesink - thinking through the problem thoroughly and the in the case of a PaaS platform sound design that will last into the future).

tl;dr - Play with Kotlin for server-side stuff, see what you think, it's quite good. Unless you're already dabbling in Haskell, F#, OCaml you'll probably be quite impressed with how they've balanced expressivity of the langauge with practical considerations, approachability, and JVM integration.

Special thanks to Vaskir for sharing his F# vs Kotlin thoughts over DM, it was the push I needed to have a stab at Kotlin.

Tags: kotlin sitepod fsharp functional golang