I primarily write c# for a living. What's wrong with async await in kotlin? I'd struggle to live without it in c#.
Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.
Why make life more difficult when you can have code that reads linearly?
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.
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.
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.
You can always call something async synchronously (by waiting for finishing). Or something synchronous in an async way (by putting it onto another thread). But there is no way to completely remove this fact from the eyes of the programmer. async/await is one of the ways to make it easier to read or write.