Isn't Kotlin coroutines have the same coloring problem (functions must be marked with "suspend").l?

Although the coloring problem is only a problem if red functions are harder to use. Not sure marking all functions with "suspend" would make it any worse, besides infecting the codebase.

Here the Kotlin lead argued that it is not a "problem".

https://elizarov.medium.com/how-do-you-color-your-functions-...

I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions.

I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?

> you still need to mark functions as suspend and only call suspending functions from other suspending functions.

You restated the idea of function colouring without further elaborating why it is a problem.

If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.

> You restated the idea of function colouring without further elaborating why it is a problem

Did you not read my second paragraph?

> I am also not sure

It felt like a question more than a complaint.

> create an interface that can be implemented by both suspending and synchronous functions

If interface has a suspending method, the implementations will also be suspending. But you can choose not to make any suspend calls in the method body. Not being able to say "this particular implementation of a red interface is blue" has never bothered me.

I guess my complaint is that it doesn’t work with object oriented programming. It’s the same reason why I don’t like checked exceptions, checked nulls, or Result types.

runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types?

If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.

You can absolutely do this.

`fun main() = runBlocking<Unit> {`

https://kotlinlang.org/docs/composing-suspending-functions.h...

Then you'll have to explain why that isn't the default main behavior then. Synchronous functions cannot call async functions (without defining N runblocking scopes) but a runblocking main would make kotlin seems color-less and should be seen as best practice. What's the catch?

> would make kotlin seems color-less

Quoting the post:

> Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code.

Also you can do `suspend fun main()`

> Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember.

I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..

The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.