5 ms·

Kotlin state of the art coroutines should be mentioned too

deepsun 4y ago
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 4y ago
  The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.
- ackfoobar 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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()`

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 4y ago
The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.
ackfoobar 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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()`