4 ms·

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 func

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.

SemanticStrengh 5y ago
The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.
ackfoobar 5y ago
Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...
- vips7L 5y ago
  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?
  - SemanticStrengh 5y ago
    > 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..
  - ackfoobar 5y ago
    > 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.
    - SemanticStrengh 5y ago
      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.
      - ackfoobar 5y ago
        You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...
        SemanticStrengh 5y ago
        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?
        ackfoobar 5y ago
        > 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()`
    - vips7L 5y ago
      > You restated the idea of function colouring without further elaborating why it is a problem Did you not read my second paragraph?
      - ackfoobar 5y ago
        > 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.

SemanticStrengh 5y ago

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

ackfoobar 5y ago

Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...

vips7L 5y ago
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?
- SemanticStrengh 5y ago
  > 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..
- ackfoobar 5y ago
  > 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.
  - SemanticStrengh 5y ago
    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.
    - ackfoobar 5y ago
      You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...
      - SemanticStrengh 5y ago
        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?
        ackfoobar 5y ago
        > 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()`
  - vips7L 5y ago
    > You restated the idea of function colouring without further elaborating why it is a problem Did you not read my second paragraph?
    - ackfoobar 5y ago
      > 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.