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.

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

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.

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.

An Async<T> is not a T whether you have the monadic sugar or not.

Why make life more difficult when you can have code that reads linearly?

In Kotlin it is just T, the function is suspend.

Then the language is implicitly converting it through suspension for you. They are still different things. What if you don’t want that to happen?

Can you provide a good cheap thread example for Java vs async/await. What I find online is horrible compared to async/await but people keep talking about function colouring etc. I just cannot see what is the issue. Nor do people give better examples; I was watching some guy on YouTube who said async/await sucks and my idea is better, then spent 30 minutes explaining his idea vaguely. No implementation, no examples.

In the simplest case, you take an async function, remove `async` and `await` keywords, and as a result you get a normal function which you can call and get a result without awaiting, which has better and more predictable performance, and a straightforward stack trace (and a simpler language syntax and semantics). All upsides, no downsides.

Probably you can think of a more complex example where it’s not that straightforward, please link code that you have in mind, we can see how with cheap threads it could be made better.