I've been playing with both Kotlin and Go recently and while I'm generally happier with Kotlin wrt syntax consistency, refactorability and familiarity (from Java), there's one thing Go has that's a really big advantage to me; Channels and Go routines.
These make async programming so much nicer and obviate all manner of common synchronization issues. If Kotlin supported equivalent functionality in as neat a syntax, it would make it a no brainer as to which laguage I’d want to use.
While supporting Go routines is syntactically easy (they are functions you can fire off asynchronously), the sort of syntax I’m talking about is stuff like:
channel <- input
and
output <- channel
And the rather neat ‘swtich’ statement that blocks for channels:
// data is the input channel for data
// stop is a channel that receives an input when it’s time to terminate
switch {
case value := <- data
// do some processing
break
case <- stop
}
You can also use channels with fixed buffer size as semaphones (they block on input as well).
I am sure someone could do all this in a library perfectly well, but it’s the super consise syntax that’s so appealing in Go.
Perhaps a ‘blocking assignment’ operator (Kotlin equivalent of ‘<-’) that would work with any Channel interface/class for example. Obviously when used in some contexts (e.g. switch) it needs to be possible to combine several pending assignments and block only until the next is available.
Then again, perhaps Kotlin has other ways up its sleve to deal with async programming that I’ve not come across yet …
I happened to be working on a goroutine implementation in Kotlin yesterday. This is what I have so far, also includes 5 examples. The select syntax is not ideal, but infix calls look good enough imho.
We have some plans on supporting ansynchronous programming on the language level, but are not sure yet which way to go. The Go way is rather radical, and there are other approaches like C#'s or F#'s async... We'll see. Thanks for the examples
As Ioannis shows, I like the idea of libraries solving asynchronous programming challenges rather than making it a core language feature per se.
There are various approaches (e.g. locks, thread pools, actor style programming, go routines, iteratees/reactive extension or “<a href=”http://hawtdispatch.fusesource.org“>grand central dispatch” style. Most of them don’t really require language changes, just a nice language with anonymous functions that make little DSLs relatively easy.
I wonder with C#'s async/await if a language change really is required. e.g. the scala Future/Promise approach lets you compose Futures to be able to ‘do stuff when a particular future is completed’ and compose futures together nicely in a non-blocking way without special language changes; using collection style “map” operations on futures to chain together asynchonous bits of code; in a similar way to composing Iterator’s together that are lazily iterated.
(The unfortunate thing is the JDK java.util.concurrent.Future is a little broken, not allowing any kind of onComplete function/listener to be registered - so like with Scala, a new Future implementation may be required).
For example this C# async await example could be rewritten in Kotlin something along the lines of this (if we had a composable Future implemention)
fun accessTheWebAsync: Future<Int> {
val client = HttpClient()
val getString: Future<String> = client.getStringAsync("http://msdn.microsoft.com")
doIndepdentWork()
return getString.map { urlContents =>
urlContents.size
}
}
Then no new keywords or language features required; just a nice composable Future library with methods like map / onComplete / onFailure etc.
Is library support sufficient to give us things like the nice blocking switch statement (in a compelling/concise syntax) ?
While I’m normally all for simple, orthogonal language + rich libraries as the solution to things, I can’t get to a version of the blocking switch statement that’s anywhere near as nice as the Go version.
Maybe I’m not wrapping my head around things in enough of a Kotlin way though.
Also note that (for what it’s worth) Guava has ListenableFuture which does the whole onComplete thing nicely (thouhg I’m not clear on what Kotlin’s stance on taking stuff from Guava is).
Hello Andrey,
This thread on supporting async programming in Kotlin is over a year old by now, but I could not find anything newer. Will post my thoughts here then.
I’m not sure if the Go like concepts that David Beaumont is talking about in the original post starting this thread are similar to C# async/await, which is something I need most in my Android (and in the future maybe other mobile) programming struggles: when ‘await’ is executed in C# code, the function returns to its caller. This return to caller is essential here. The internal context is saved, so that when the “awaited” code finishes, the language or frameword can resume execution within the aborted function code at the point just past ‘await’ line.
This is important in many GUI frameworks, including Android framework, which at the ‘await’ point can return to the GUI looper, and handle other Android activities or just display a spinning progress indicator, whatever. I tried to implement something like this by creating a new Android looper with Java code and wait within the function, but this only crashes an app in most cases. The “return to caller” part of ‘await’ is essential, and a later re-start of the function from the ‘await’ line with the saved context, too.
Why won’t I just switch to using C# for my Android programming, using existing frameworks like Xamarin or Dot42? Well, I have an existing, pretty big app already written in Java, and so far neither Dot42 nor Xamarin support library C# projects that could be called from Java. With Kotlin on the other hand, I can freely mix Kotlin and Java modules in one project, which is sweet, but then Kotlin still does not do proper async/await. Please consider supporting C# style async/await in Kotlin. Thanks!
- so like with Scala, a new Future implementation may be required).