3 ms·

Kotlin coroutines are amazing. They're built on very clever tech that converts fairly normal source code into a state machine when compiled. This has huge benef

Kotlin coroutines are amazing. They're built on very clever tech that converts fairly normal source code into a state machine when compiled. This has huge benefits and allows the programmer to break their code up without the hassle of explicitly programming callbacks, etc. https://kotlinlang.org/spec/asynchronous-programming-with-coroutines.html https://kotlinlang.org/spec/asynchronous-programming-with-co... However... an unavoidable fact is that converted code works differently to other code. The programmer needs to know the difference. Normal and converted code compose together differently. The Kotlin compiler and type system helps keep track, but it can't paper over everything. Having lightweight thread and continuations support directly in the VM makes things very much simpler for programmers (and compiler writers!) since the VM can handle the details of suspending/resuming and code composes together effortlessly, even without compiler support, so it works across languages and codebases. I don't want to be critical about Kotlin. It's amazing what it achieves and I'm a big fan of this stuff. Here are some notes I wrote on something similar, Scala's experiments with compile-time delimited continuations: https://rd.nz/2009/02/delimited-continuations-in-scala_24.html https://rd.nz/2009/02/delimited-continuations-in-scala_24.ht... I think this is a general principle about compiler features vs runtime features. Having things in the runtime makes life a lot easier for everyone, at the cost of runtime complexity, of course. Another one I'd like to see is native support for tail calls in Java. Kotlin, Scala, etc have to do compile-time tricks to get basic tail call support, but it doesn't work across functions well. Scala and Kotlin both ask the programmer to add annotations where tail calls are needed, since the code gen so often fails. https://kotlinlang.org/docs/functions.html#tail-recursive-functions https://kotlinlang.org/docs/functions.html#tail-recursive-fu... https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.html https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.... https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.html https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.htm... As a side note, I can see that tail calls are planned for Project Loom too, but I haven't heard if that's implemented yet. Does anyone know the status? "Project Loom is to intended to explore, incubate and deliver Java VM features and APIs built on top of them for the purpose of supporting easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform. This is accomplished by the addition of the following constructs: * Virtual threads * Delimited continuations * Tail-call elimination" https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main

SemanticStrengh 4y ago
Coroutines are much less coloured than async await programming though since functions returns resolved types directly instead of futures. But yes there is the notion of coroutine scope but I don't see how to supress it without making it less expressive. Very few people know it but Oracle is developping an alternative to Loom, in parallel. https://github.com/oracle/graal/pull/4114 https://github.com/oracle/graal/pull/4114 BTW i expect Kotlin coroutines to leverage loom eventually. As for the tailrecursive keyword, it is not a constraint but a feature since it guarantee at the type level that this function cannot stack overflow. Few people know there is an alternative to tailrecursive, that can make any function stackoverflow safe by leveraging the heap via continuations https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-deep-recursive-function/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-deep-re... As for Java, there is universal support for tail recursion at the bytecode level https://github.com/Sipkab/jvm-tail-recursion https://github.com/Sipkab/jvm-tail-recursion
- gavinray 4y ago
  Thanks for posting that link to Java tail recursion library, super handy + didn't know about it. You need tail recursion for writing expression evaluators/visitors frequently. I've been using an IntelliJ extension that can do magic by rewriting recursive functions to stateful stack-based code for performance, but it spits out very ugly code: https://github.com/andreisilviudragnea/remove-recursion-inspection https://github.com/andreisilviudragnea/remove-recursion-insp... > "This inspection detects methods containing recursive calls (not just tail recursive calls) and removes the recursion from the method body, while preserving the original semantics of the code. However, the resulting code becomes rather obfuscated if the control flow in the recursive method is complex." It was this guy's whole Bachelor thesis I guess: https://github.com/andreisilviudragnea/remove-recursion-inspection/blob/master/thesis/thesis.pdf https://github.com/andreisilviudragnea/remove-recursion-insp...
- ohgodplsno 4y ago
  > Coroutines are much less coloured than async await programming though since functions returns resolved types directly instead of futures Only because the compiler does its magic behind the scenes and transforms it into bytecode that takes a lambda with a continuation. Try calling a suspend function from java or starting a job and surprise, it's continuations all the way down

SemanticStrengh 4y ago

Coroutines are much less coloured than async await programming though since functions returns resolved types directly instead of futures. But yes there is the notion of coroutine scope but I don't see how to supress it without making it less expressive. Very few people know it but Oracle is developping an alternative to Loom, in parallel. https://github.com/oracle/graal/pull/4114 https://github.com/oracle/graal/pull/4114 BTW i expect Kotlin coroutines to leverage loom eventually. As for the tailrecursive keyword, it is not a constraint but a feature since it guarantee at the type level that this function cannot stack overflow. Few people know there is an alternative to tailrecursive, that can make any function stackoverflow safe by leveraging the heap via continuations https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-deep-recursive-function/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-deep-re... As for Java, there is universal support for tail recursion at the bytecode level https://github.com/Sipkab/jvm-tail-recursion https://github.com/Sipkab/jvm-tail-recursion

gavinray 4y ago
Thanks for posting that link to Java tail recursion library, super handy + didn't know about it. You need tail recursion for writing expression evaluators/visitors frequently. I've been using an IntelliJ extension that can do magic by rewriting recursive functions to stateful stack-based code for performance, but it spits out very ugly code: https://github.com/andreisilviudragnea/remove-recursion-inspection https://github.com/andreisilviudragnea/remove-recursion-insp... > "This inspection detects methods containing recursive calls (not just tail recursive calls) and removes the recursion from the method body, while preserving the original semantics of the code. However, the resulting code becomes rather obfuscated if the control flow in the recursive method is complex." It was this guy's whole Bachelor thesis I guess: https://github.com/andreisilviudragnea/remove-recursion-inspection/blob/master/thesis/thesis.pdf https://github.com/andreisilviudragnea/remove-recursion-insp...
ohgodplsno 4y ago
> Coroutines are much less coloured than async await programming though since functions returns resolved types directly instead of futures Only because the compiler does its magic behind the scenes and transforms it into bytecode that takes a lambda with a continuation. Try calling a suspend function from java or starting a job and surprise, it's continuations all the way down