4 ms·
A major consumer of async needs those seams. You often need the coloring because in many situations you want explicit control of what will yield execution. You
by jayd16 5y ago
A major consumer of async needs those seams. You often need the coloring because in many situations you want explicit control of what will yield execution. You might want to hold on to a UI thread or a specific OS thread for interop. A choice of all sync or all async is not good enough either.
There might be some better syntax with scopes but Kotlin hasn't been able to do away with the off the UI thread problem.
I won't say we'll never solve it but I don't think the solution is here yet.
- dcow 5y agoI'm not suggesting one or the other all in and neither does the article. I think you'd be quite happy with the full proposal. You can control whether you get the async or sync version by calling from an async or sync closure, respectively, essentially.
- jayd16 5y agoYes, I think we mostly agree. I was trying to add some context to the problem. I apologize that my slightly more pessimistic take on where we currently are was construed as disagreement.
- saurik 5y agoThis problem was already solved a long time ago: asynchronous execution is a monad (as is error handling and list comprehension and any number of other fun features), and do syntax is that syntax sugar people are looking for that lets you decide to dip below the abstraction on a case by case basis... only no one seems to want to build support for monads into their language as they think they are too complicated or smell like haskell (is that even a bad thing?!) or something (and then you get awkward stuff like Rust deciding to take the data structure from a popular monad--Either, as Result--but providing none of the scaffolding or behaviors or synergistic language features to make it pleasant to use :/).