Give Kotlin And Quasar a Try30 May 2015
Hello hello! After a quick incursion into the world of
Rust language, I’m back!
The balance since last year when I started to work on a tracking system written in Go is: I didn’t finish it (as if it is novelty). Also, I had the opportunity to deliver a danjgo system to production with easy. I might return with the tracking stuff but not written in Go.
Ok, so I’m here to give my 2 cents on a Language that I - have to admit - ignored for a long time. A language that was launched ~5 years ago, when Scala was taking over: Kotlin. You can find better details about why Kotlin in their blog.
To be precise, yesterday they launched the M12 with relevant changes. The good thing is that those guys are not afraid of improving the language and deprecate things for good reasons.
- Serious crafters. These guys are building a language, different from other groups that are creating a language as a masquerade just to embed a bunch of social experiments and social ideas behind them
- Incredible interop with Java without bizzarre workarounds. That is why Kotlin can take advantage of all Java libs without having to reinvent the wheel using the language.
- Statically typed, compiled. I’ve been working with Groovy (Grails) for at least 3 years. You can say “you can write tests to give you some safety”, ok, I respect, but I had to pay the price of dynamicity in production. What is not cheap.
- Null is welcome, but without NPE. Some languages wind their optinal values in a object (
Either, etc). Kotlin uses the concept of Null Safety where you give a hint to inform if a value can be null, so the compile prevents accidental code without forcing you to write defensive code
- Lambdas - Needless to comment
- Inlining - This is a super important direction to go. Hope that with Java 9, we developers become more responsible and active int terms of how compiler treats our code
- Data Classes - Imagine a very concise and short way to code a class that just holds values, but providing
copyautomatically. Data classes are the answer
- Native delegation - I can’t count how many times I had to use a delegate but doing everything by hand. Kotlin supports this pattern directly, take a look here.
- No checked exceptions \o/ -The compile never complies if you don’t
And how could I feel the language? Simple: writing a project with it. That is why I ported a
systemd like process monitor from
Rust to Kotlin. Krust-pm can be found in this Github repo.
Quasar provides light Fibers and Actors to JVM and the release 0.7.0 also got released yesterday. So, lets check.
If you open krust-pm project you’ll see that at least two classes extends from ProxyServerActor.
ProxyActor is part of the excellent builtin Behavior Actors provided. This specific one creates a proxy of your class, that immediately becomes an actor without having to implement
doRun or create a loop and pattern matching incoming messages. This is super, but might add a neglible overhead.
There are other provided behaviors like
EventSource and the great FiniteStateMachine that I want to taste.
So, the next great thing about Galaxy is the Strand abstraction. Krust-pm, due to the nature o Java system process handling, employs a thread per managed process instance. And to keep a single uniform API around a thread that manages a process or any other fiber that can do anything different, I used the
of static method from Strand to instantiate directly from a thread.
Moreover, if you are interested in distributing Actors across machines, there is a natural integration with Galaxy available.
Both Quasar and Kotlin are proving themselves as great tools to keep in mind when developing your next solution. Kotlin because it is statically typed, better than java and still flexible enough to foster elegant, expressive and intuitive code.
And Quasa because it doesn’t impose any crazy concept like other Actor libs out there, also, it offers great abstractions and a straight to the point API.