[joe_fishfish]

Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs.

It’s not hugely helpful for a UI-bound application which occasionally needs to move some work into a background thread to cut down on UI jank.

Kotlin’s suspending function syntax effectively lets you know which operations are going to (potentially) take a while, so you can make sure the UI thread isn’t blocked, and also make sure you’re communicating to the user that something is happening.

[nlitened]

If I understand your point correctly, you say that suspend keyword gives you a hint for which functions are long running, so that you run them in a background thread.

I think that’s a very flawed assumption. Some IO operations are pretty fast, like reading a local filesystem, and can be done in the UI thread, while some heavy non-async functions are accidentally O(n^2), and freeze your IO thread.

And if you say that “of course you should know what you’re doing”, then I think that suspend syntax just adds extra complexity without much semantic benefit.

[kasperni]

Custom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.

[invalidname]

Loom has zero impact on client, sure. But I disagree that async is better for client. It makes it much harder to debug and track issues.