Astoundingly, Kotlin doesn't seem to provide suspending versions of InputStream and OutputStream.
It's not hard to roll your own, but that doesn't give you the kind of default compatibility with other code that these ubiquitous interfaces provide in Java.
What would I use for suspending stream interfaces in Kotlin if I wanted to maximize interoperability without adapters?
I think that the primary way for doing IO with purely Java APIs is just calling blocking methods in the context of Dispatchers.IO.
However, there is ktor-io library by JetBrains that implements IO in a purely suspending way.
Related
Dart makes asynchronous programming extremely easy. All you need to do is surround the asynchronous code in an async method, and within it, use await before every call that is going to take a while.
I'm new to Kotlin, and asynchronous programming doesn't seem that simple here. (Probably because Dart is single-threaded.)
It'd be nice to get a rough outline of the differences both languages provide in their implementation of asynchronous code.
Apologize if I miss-stated any facts. Thanks in advance!
Dart makes asynchronous programming extremely easy. All you need to do is surround the asynchronous code in an async method, and within it, use await before every call that is going to take a while.
Yes (though async+await is not Dart's invention, it dates back to at least C# 5.0 in 2012, which then directly inspired JavaScript, Python, Julia, Kotlin, Swift, Rust, many others, and Dart).
I'm new to Kotlin, and asynchronous programming doesn't seem that simple here.
Kotlin 1.1 has async+await, although await is a postfix method, not an operator unlike in most other languages, but the end-result is the same.
It'd be nice to get a rough outline of the differences both languages provide in their implementation of asynchronous code.
Kotlin and Dart are different languages because they solve different problems, consequently there's simply too much to write about their differences, even when focused entirely on how they handle concurrency and coroutines.
...but in-short, the main difference (as far as you're concerned) is syntactical (which is as far as I can tell: Be aware that I am not a Dart/Flutter nor Kotlin expert, I just know how to read documentation and use Google)
I suggest seeing some simple examples in Kotlin, such as:
First-off, read the announcement where await was introduced to Kotlin 1.1: https://kotlinlang.org/docs/whatsnew11.html#coroutines-experimental
And seeing how it interops with Swift's async + await functions here: https://kotlinlang.org/docs/whatsnew1530.html#experimental-interoperability-with-swift-5-5-async-await (Swift's async features work the same way as Dart's, as far as I know, except without enforced thread isolation)
Kotlin Coroutines Async Await Sequence
This article (which I only skimmed) seems good too: https://www.raywenderlich.com/books/kotlin-coroutines-by-tutorials/v2.0/chapters/5-async-await
I'm new to Kotlin, and asynchronous programming doesn't seem that simple here.
In fact, Kotlin takes it to the next level of simplicity: it's almost invisible. For example:
suspend fun main() {
println("Hello")
delay(1000)
println("Hello again")
}
This code, unbeknownst to you, is actually implemented as asynchronous. But you just see simple, sequential code. The compiled code (in case of the JVM backend) has structure something like this:
public static void main(String[] args) {
System.out.println("Hello");
globalThreadPool.scheduleAfterDelay(() -> {
println("Hello again");
}, 1000, TimeUnit.MILLISECONDS);
}
On top of that, Kotlin makes it super-simple to adapt any async code you may have today so that you can use in the same native way as the above built-in delay function.
Where people trip up mostly is not this basic scenario, but dealing with more advanced topics like structured concurrency, choosing the right thread pool to run your code, error propagation, and so on.
I haven't studied Dart, but from what I know about the async-await pattern in other languages, whenever you call an async function, you have implicitly created a concurrent task, which is very easy to leak out -- all it takes is forgetting to await on it. Kotlin prevents these bad outcomes by design and forces you to address the concurrency you're creating head-on, instead of decyphering out-of-memory logs from production.
The most important difference, beside the syntax, is the multithreading model of these languages.
Check this article:
Dart supports multi-threading using Isolates. Right in the introduction to Isolates, it has been said that
isolates [are] independent workers that are similar to threads but don’t share memory, communicating only via messages.
While Kotlin (on JVM) uses Java threads under the hood, which have access to shared memory.
async/await in both languages is implemented roughly the same, using CPS (glorified callbacks). The important distinction, in Dart you have single threaded event loop dispatching these callbacks, while in Kotlin on JVM you can have multiple event dispatches working together and continuations (callbacks) running truly in parallel on different threads and sharing memory, with all the benefits and issues resulting from that.
Also, note, Kotlin aims to be a multiplatform language, so while on JVM it has multithreaded model, if you compile Kotlin program into JS backend, it would be single-threaded with event-loop, basically same as Dart.
P.S. Watch this video from Roman Elizarov (designer of coroutines in Kotlin), is has a good overview of coroutine usage and internals.
When we use coroutine, we can either have the normal kotlin coroutine or the native-mt version.
i.e.
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.0'
or
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.0-native-mt'
Is there any difference between them? When should we use which?
It basically provides capability to use multiple threads in Kotlin/Native code (typically as part of a Kotlin Multiplatform (KMP) project). Some more info at https://kotlinlang.org/docs/mobile/concurrency-and-coroutines.html#multithreaded-coroutines. This is also version used now by many KMP libraries (e.g. Ktor) and is generally a requirement when developing KMP apps.
My question is rather theoretical.
I am quite new to kotlin (only passed the tutorial, didn't write any real code).
Reading through the language reference I find myself confused about the fact that "suspend" is a keyword, yet I can't find anything like "launch" in the list of keywords. That makes me think that there is some asymmetry - the "suspend" is a compiler feature, yet "launch" is a library function. Is my understanding correct? If so - wouldn't it have been better to implement both as library features or both as compiler features?
I always thought that you can always write your own standard library using the available language features, but I still can't see if this really applies to this case.
TL;DR: Can I start a coroutine using pure kotlin, without importing any libraries whatsoever (however ugly that would be)?
The suspend marker adds a hidden continuation parameter to the function signature and completely changes the implementation bytecode. Suspension points don't boil down to helper function calls, they turn your linear program code into a state machine, the state being kept in the continuation object. The resulting bytecode isn't even representable as Java program code.
As opposed to that, launch is just regular library code that builds upon the suspend/resume primitive.
#Alexey Soshin's isn't quite correct.
You can use coroutines w/o the library, and it's pretty easy. Here is a about the simplest suspending coroutine example that has 0 dependency on the coroutine library.
import kotlin.coroutines.*
fun main() {
lateinit var context: Continuation<Unit>
suspend {
val extra="extra"
println("before suspend $extra")
suspendCoroutine<Unit> { context = it }
println("after suspend $extra")
}.startCoroutine(
object : Continuation<Unit> {
override val context: CoroutineContext = EmptyCoroutineContext
// called when a coroutine ends. do nothing.
override fun resumeWith(result: Result<Unit>) {
result.onFailure { ex : Throwable -> throw ex }
}
}
)
println("kick it")
context.resume(Unit)
}
This runs fine on the play.kotlinlang.org site.
As you can see from this code, any lambda decorated with suspend has the startCourtine() on it.
In fact, I think the SequenceBuilder() from the standard collection classes uses a simple coroutine like this to generate the sequence, with no dependency on the coroutine library.
The compiler is doing the heavy lifting on the coroutines, splitting the code into different "methods" at each possible suspending point. Look at the java code for this, and you'll see it's "split" into a switch statement. one case before the suspend, and another after.
The library does a ton of nice stuff for you..... and it's likely you'll almost always use it (cuz why not?) but you don't actually need it.
Can I start a coroutine using pure kotlin, without importing any libraries whatsoever (however ugly that would be)?
No. All coroutine generators are inside kotlinx.coroutines library, so you'll need at least that. Now, very theoretically, you could reimplement this functionality yourself. But probably you shouldn't.
How this can be done is a bit too long for a StackOverflow answer, but try invoking method of this Kotlin class from Java:
class AsyncWorks {
suspend fun print() {
println("Hello")
}
}
You'll see that although Kotlin method has no arguments, in Java it requires Continuation<? super Unit>. This is what suspend keyword does. It adds Continuation<T> as the last argument of our function.
wouldn't it have been better to implement both as library features or
both as compiler features?
Ideally, you'd want everything to be a "library feature", since it's easier to evolve. Removing a keyword from a language is very hard. In theory, having suspend as a keyword could be avoided. Quasar, being a framework, uses annotations instead. Go programming language, on the other hand, assumes all functions are suspendable. All those approaches have their advantages and disadvantages.
Kotlin decided to be pragmatic, and add suspend keyword, leaving the decision on the developers. If you're interested in the topic, I highly recommend this talk by Roman Elizarov, author of Kotlin coroutines, that explains their decissions: https://www.youtube.com/watch?v=Mj5P47F6nJg
Answering my own question here.
After a year of Kotlin I tend to think that this IS indeed possible.
The suspend language feature creates an extra class and instantiates it every time your suspend function is called. This class extends ContinuationImpl and stores the progress of your coroutine - to which point it was able to execute so far.
Therefore one will need to write a custom dispatcher that would be able to manage the queue of the continuation objects to decide which one has to run now and a launch function that would take the newly created continuation object and pass it over to the dispatcher.
Now, this is still an asymmetry - the ContinuationImpl lives in kotlin.coroutines.jvm.internal so the compiler assumes this package exists. If one really wants to drop the standard library altogether - he'll need to implement that package to be able use the suspend keyword.
I'm not a kotlin expert though, so I might be wrong.
Because coroutines are valid for use cases that don't support launch. Because suspend requires some specific support from the compiler and launch doesn't if you already have suspend. Because structured concurrency is a library framework on top of the language feature, and launch is a part of that specific framework, that makes specific choices on top of what the language requires.
Starting a coroutine without any libraries can be done with startCoroutine. kotlin.coroutines is part of Kotlin, not a library.
I’m looking for a multi-platform alternative to input streams. My concrete task is to fetch an encrypted file from a remote server via https and decrypt it on demand.
In Java land I would an implement InputStream which proxies the reads to the input stream from the https library. How can I do the same in kotlin targeting multiple platforms.
I see ktor returns an ByteReadChannel, but I don’t know which functions.
I’m lost and don’t know where to start. Thanks for your help in advance.
If the framework you are using does not provide you with a full-fledged InputStream implementation, the only chance left is to write your own. Much like what the ktor developers did: ByteReadChannel is just an abstraction of "reading bytes from a channel".
This abstraction lives in the common part and allows to write application and business logic around it.
The key to make this work in the context of a Kotlin Multiplatform project is, the actual implementation needs to be provided in the platform specific parts. The JVM specific code of the ktor project actually has an implementation that uses InputStream: InputStream.toByteReadChannel.
You certainly don't have to do it like your example from the ktor project and model everything down from byte channels up to file representations. If you want to leverage Kotlin framework classes, Sequences might be handy. This could look something like this:
// in common
interface FileFetcher {
fun fetch(): Sequence<Byte>
}
expect fun fileFetcher(source: String): FileFetcher
// in jvm
class JvmFileFetcher(val input: java.io.InputStream): FileFetcher {
override fun fetch(): Sequence<Byte> = input.readBytes().asSequence()
}
actual fun fileFetcher(source: String): FileFetcher {
val input = java.net.URL(source).openStream()
return JvmFileFetcher(input)
}
You would define an interface FileFetcher along with a factory function fileFetcher in the common part. By using the expect keyword on the fileFetcher function you need to provide platform-specific implementations for all target platforms you define. Use the FileFetcher interface in the common part to implement your logic (decrypting file contents etc.). See the documentation for Sequence for how to work with it.
Then implement the factory function for all platforms and use the actual keyword on them. You will then need to write platform-specific implementations of FileFetcher. My example shows how a JVM version of the FileFetcher interface.
The example is of course very basic and you probably would not want to do it exactly like this (at least some buffering would be needed, I guess). Also, within the JVM part you could also leverage your favorite networking/HTTP library easily.
I'm new to Kotlin, but I want to try using it for game development, targeting at least Android with OpenGL ES 2.0 and HTML5 with WebGL (with which I am reasonably familiar). Not having to have slightly different versions of my rendering engine's classes/functions for WebGL and GLES20 would obviously be a good thing, but is there a practical way to achieve this in Kotlin without overhead?
I think what I'll have to do is write a class that implements WebGLRenderingContextBase or a clone of it (if a clone is necessary I can just use a delegate for the WebGL implementation) in OpenGL ES 2.0, full of methods like this:
override fun bindBuffer(target: Int, buffer, Int) {
GLES20.glBindBuffer(target, buffer)
}
I'll write a script to do the bulk of the work.
My question is, is the compiler smart enough to optimise away such wrappers and use GLES20.glBindBuffer etc directly in my class' vtable, or whatever equivalent the JVM has? Presumably inline can't be of any use when calling an overridden method via a reference to an interface or base class.
The Kotlin compiler does not optimize the bytecode to this extent, and it does not need to: the JVM itself is quite good at optimizing the code.
Moreover, inline functions were not designed to be a performance tool in Kotlin, instead they are used for non-local control flow and code transformation that cannot be achieved without inlining.
Actually, the JVM performs a lot of optimizations, sparing the compilers from the necessity of optimizing the bytecode they generate on their side too much. And inlining is one of the optimizations the JVM can do. (1) (2) (3)
Though neither compilers nor JVM can inline native methods, because of completely different nature of the native code.
The Kotlin compiler, in turn, performs some local optimizations that do not affect the overall structure of the program. One more reason to do so is debugging experience which is hard to preserve with heavy optimizations. To check the exact Kotlin optimizations, you can try to disable them by adding the -Xno-optimize flag to the free compiler arguments, then look through the generated bytecode or do some benchmarking.