Server-side Kotlin with Coroutines • Roman Elizarov • GOTO 2019

This presentation was recorded at GOTO Chicago 2019. #gotocon #gotochgo

Roman Elizarov - Kotlin Libraries Team Lead at JetBrains

ABSTRACT
Kotlin was designed as a general-purpose programming language and with coroutines writing server-side code is a easy as never before on JVM. We'll dissect scalability and reliability problems of a traditional thread-based stacks and discuss the process of mitigating those issues by introducing asynchrony with Kotlin coroutines. We'll see how coroutine-based design naturally avoids common pitfalls of traditional asynchronous programming such as resource management, error handling and request cancellation, producing safe [...]

TIMCODES
0:00 Introduction
1:51 Old-school client-server monolith
2:32 Sizing threads - easy
4:08 Complex business logic
5:22 What if a service is slow?
5:40 Blocks threads
7:43 Release the thread
10:47 Suspend behind the scenes
11:42 Performance!
13:43 Integration
14:44 Release thread?
14:58 Blocking server
15:50 Asynchronous server
16:40 Server integrated with coroutines
17:30 Server not integrated with coroutines
19:23 Suspend is efficient
21:14 Let's go deeper (with coroutines)
21:49 Call stack with coroutines
23:26 Thread pools
27:51 CPU-bound code
28:14 Fine-grained control and encapsulation
33:14 Concurrency with async (futures)
35:25 Concurrency with coroutines
38:04 Without coroutine scope?
38:54 Convention
39:41 Types as documentation
40:35 Types are enforced
42:46 Green threads / Fibers
43:25 Fibers promise
44:40 Solution - shared thread pool
45:54 Returning many responses
48:02 Where's the catch?
50:14 Flow example

Download slides and read the full abstract here:

#kotlin #programming #ProgrammingLanguages

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[arhyth]

question from an outsider POV, neither Java nor Kotlin developer here: why not go further and move the burden of managing threads away from the programmer to the runtime. the runtime can dynamically allocate threads as needed instead of being configured (at compile time, i assume) by the programmer.

[samferrer]

Well, in the good old scary days you used fork ...

[robchr]

So map and flatMap is bad unless you use a flowable?

[pixelPlex]

Are Kotlin Flows a high level concurrency model?

[samferrer]

36:54 ... why not call it "transaction" instead of "coroutineScope"?

[adityaparikh]

How is flow different from Reactive Programming Mono & Flux?