Talking Kotlin podcast: interview with Roman Elizarov

 

There is a really interesting interview with Roman Elizarov, the language lead for Kotlin, on the Kotlin by JetBrains YouTube channel. Being a library developer in the past, Roman explains very clearly what the motivation is to include certain features in a library and when to add new features to the Kotlin programming language. He also shares some information about the Kotlin language team at JetBrains and what their focus is. Kotlin, being promoted as a modern language, also has to keep up with market trends in order to stay ‘modern’.

Posted in Blog, Kotlin, Podcast | Leave a comment

Akka and Kotlin coroutines: ♡

I’ve experimented with Kotlin and coroutines in programming Akka. And I must say, I really like the combination so far. But before I go into it some brief preliminaries for those who don’t know Akka and actors.

Actors and Akka

Actors are a programming model that fits cloud native architectures particularly well. Being highly available and scaling horizontally. All while embracing the realities of multiple servers collaborating, server instances coming and going and the network having hickups.

On the JVM Akka is the prominent actor framework. It’s been around for a while now and as a result it’s highly reliable, well thought out and offers a wide programming eco system. My own interest in Akka is because of its suitability for software systems that can only be built with business events as a key construct and thinking model.

And then of course materialized views, CQRS and near real-time data streams play a big role in constructing those systems.

Akka and Java programming; the challenge

Akka’s Java api can be a bit unwieldy I find. Which is to be expected since Java as a programming language is still lagging quite a bit compared to newer programming languages.

And because Akka actors have to be non-blocking in their implementation. Which means extra bookkeeping we have to do to maintain intermediate state that would otherwise be handled by the JVM stack.

So I thought I’d see what Kotlin and coroutines can do to improve the programming experience. Trying to make the programming model feel as much native Kotlin coroutines as I can.

Akka and Kotlin coroutines demo

Our example actor receives requests with a sequence number, keeps a counter of processed messages, does a call to a slow service and sends a response using this data. For this example the actor has to process messages sequentially.

During the call to `slowService` we can’t block the thread because that would make the actor unresponsive to system messages. Instead with the Java api we’d have to kick off the Java `CompletableFuture`, make sure the result when it becomes available is sent to ourselves, go to a waiting mode where we stash all incoming messages for later processing, and when we do receive the result we get our stored message, send the end result and go back to processing mode.

All perfectly doable but the required call stack bookkeeping obscures the high level intent of what we’re trying to do.

By contrast using Kotlin suspend functions and coroutines the functionality of our actor is just as easy to read as blocking code. The message that we’re currently processing is still in scope after the service call so we can just use it and service response to return a result. But it’s still _non blocking_ code. So how does that work?

The `ChannelActor` is an Akka actor that is a `CoroutineScope`. So that we can launch a coroutine (think of it as a lightweight thread) in our actor and be confident that coroutine is stopped when the actor is stopped.

When the actor is started with `startReceive` we kick off a coroutine to start processing messages. IntelliJ shows next to `startReceive` that we get a `this: ActorScope` to work with. As a result we have a `ReceiveChannel` that’s the inbox of our actor. (See below for more information on the signatures.) We can maintain mutable state `counter` since we have one single coroutine doing the processing. With our `for` statement we’re looping over a suspending iterator. To the left you see a a special arrow icon in IntelliJ that indicates that our code will suspend there. Only to continue when we receive a message. We see the same icon next to the call to slowService. So the processing will suspend until we get a response. And then the actor can return the result. Suspending until the next message comes in.

But what if our `slowService` call is _too_ slow? Of course we configured our underlying http client and circuitbreaker with a timeout. Our `slowService` suspend function will throw an exception in that case. In our current actor that exception is unhandled and our processing of messages will be aborted. We decide that we want to return an exception message to our client in that case and continue processing.

We can use standard `try` `catch` exception handling for this.

Running our actor

So how do we run our demo actor and see that it works?

For testing purposes with runAkka we get an Akka actor system in scope and we’re in a coroutine scope so we can call suspend functions and launch coroutines. With the extension function `demoActor` we get a reference to our actor. Next to our call `channelActor.getCounter` we see the icon which tells us our code will suspend there until we get a result or it times out.

We use Kotlin extension functions to document the protocol of our demo actor.

Conclusion

Personally I really like how well Akka actors and Kotlin coroutines work together. It makes for a very accessible programming model I find. This demo uses Akka classic actors. It’s programming model is a natural fit with Kotlin coroutine channels. I’m still chewing on what a Kotlin coroutine version of Akka typed would look like. In a follow up post I’ll go into the design principles of Kotlin and coroutines they work out in this api.

PS: actors

You may wonder why go to all this trouble when there are already [actors available](https://kotlinlang.org/docs/shared-mutable-state-and-concurrency.html#actors) as part of Kotlin coroutines. The difference is that Kotlin coroutine actors are a great way to manage mutable state in the face of concurrency.

But they are confined to the memory of one process. They aren’t remote addressable, do not survive a server rebooting and can’t collaborate across server instances.

Akka actors on the other hand can live in a cluster of servers and thus be highly available and scale horizontally. They can be persistent and thus are very suitable for CQRS.

PPS: some supporting information

The `this: ActorScope` type is as follows

where `ReceiveChannel` is a standard Kotlin receive channel. `ActorScope` extends Kotlin `CoroutineScope` so that we can safely launch coroutines.

The `startReceive` method has the following signature

It uses Kotlin receiver functions which are idiomatic in Kotlin coroutine programming. The block is suspending so we can call suspending functions like `slowService`.

Another way of handling the messages would be

The signature of the `runAkka` method is as follows

Where `AkkaScope` extends `CoroutineScope` to allow launching coroutines and provides the actor system

This article was first posted on github: https://gist.github.com/joost-de-vries/479bbd285c4de23cb5bade21d83e2e22

Posted in Blog, Kotlin | Leave a comment

Include runnable Kotlin code snippets in your WordPress posts

JetBrains offers a great online environment, Kotlin playground, where you can play around and share Kotlin code fragments. This environment offers an option to embed code fragments from the Kotlin Playground into your website using an iframe. This does not always play nicely with WordPress. Luckily there is a WordPress plugin available that allows for including runnable Kotlin code into your WordPress posts.

Tip from our side, try to edit in text mode only, we noticed that indentation is being stripped from the code snippets when using this plugin in the visual editor, which is rather annoying. You could also revert back to the classic editor in WordPress. See this github ticket for more details: https://github.com/Kotlin/kotlin-playground-wp-plugin/issues/9

Try the example below yourself:

The plugin can be downloaded from the Kotlin github page: https://github.com/Kotlin/kotlin-playground-wp-plugin 

Posted in Blog | Leave a comment

NLKUG @ appdevcon.nl

This year we want to work a bit more on promoting the Dutch Kotlin User Group (NLKUG). We are looking for bloggers and/or other Kotlin enthusiasts in the Netherlands who want to help us out.

With a big thanks to appdevcon.nl we will be promoting NLKUG @ appdevcon.nl this year. If you want to meet us there you can still buy tickets with a discount voucher specially for NLKUG visitors. The following voucher entitles for a 5% discount for the appdevcon.nl conference: nlkugp20

Hope to see you there!

Posted in Uncategorized | Leave a comment

Kotlin 1.3 Released

Four days ago, Kotlin version 1.3 was officially released to the general public. This release adds a lot of highly anticipated features, amongst which are:

  • Coroutines now stable: After being an experimental feature for quite some time, Jetbrains have now decided the time has come to mark coroutines as a stable feature. It is not integrated in the core language, but still an add-on that Kotliners can opt-in for.
  • Kotlin 1.3 introduces support for multiplatform tooling, which should make it easier to support multiple platforms. So other than just supporting JVM based platforms, using these tools makes it easier to also support Android, JavaScript and even native as target platforms. Support is available for HTTP, serialization and couroutines, to name a few.
  • Several minor features added to the language, compiler and/or tools and plug-ins, amongst which:
    • Experimental support for inline classes (for better performance
    • Experimental support for unsigned integers
    • When expressions now expose the subject so you won’t need to assign it to a variable yourself
    • Contracts added to improve static analysis of library calls
    • No-arg main method
    • Sequence debugger for visualizing lazy computations
    • Scratch, REPL and scripting improvements
    • Standard library expanded to Kotlin/Native and support for Kotlin/JS
    • Experimental incremental compilation for Kotlin/JS

More detailed info on the release is available on the Jetbrains website.

All in all a good release and a solid update that finally gives us the stable version of coroutines. We’ve already upgraded, you too?

Posted in Blog, Kotlin | Leave a comment