4 ms·

Are there any popular UI frameworks/architectures that are actually compatible with implicit context switching? I see a lot of desire to purge await from langu

by jayd16 5y ago

Are there any popular UI frameworks/architectures that are actually compatible with implicit context switching? I see a lot of desire to purge await from languages but I find the explicit control necessary. What would UI code look like with implicit yields?

bluquark 5y ago
Kotlin is used to write UI code, and potentially-yielding methods are called with ordinary function call syntax. Kotlin does not have the "await" keyword, but it does have an analogue to the "async" keyword, called "suspend". Here is a post from Kotlin's language designer on their philosophy: https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...
- jayd16 5y ago
  Kotlin has context blocks instead of the looser context hopping continuation syntax of C# but it seems like it's trading one explicit syntax for another. You can still get off main thread runtime exceptions in Kotlin on Android, so it doesn't solve the issue entirely. I think that just shows how necessary some kind of explicit syntax is, despite all the talk I see that it's unnecessary. I would love to see more examples though, or a Kotlin native UI.
  - bluquark 5y ago
    Agreed. The only major language I know of where it's fully implicit is Go, which is rarely used for UI. > I would love to see more examples though, or a Kotlin native UI. Jetpack Compose is a Kotlin-native UI framework. Here are some examples of how it uses coroutines: https://developer.android.com/jetpack/compose/kotlin#coroutines https://developer.android.com/jetpack/compose/kotlin#corouti...
metaltyphoon 5y ago
C# uses “implicit context switch” on its async/await as it captures the current SynchronizationContext by default. On WPF/winforms/UWP and classic ASP there is one, so unless you other wise tell it, the await always comes back on the UI thread. Console and ASP net core have null as their SynchronizationContext.
- jayd16 5y ago
  C# will not context switch until you yield execution with an await. There is some default continuation setup that will happen if you use the Task Parallel Library (where the context management is explicit but abstracted away inside the library) but that's a different thing.
- DaiPlusPlus 5y ago
  > it captures the current SynchronizationContext by default. Which results in the majority of async code, which doesn't run in a UI context, needing to spam `.ConfigureAwait(false)` everywhere. It's the most visible wart in C# today - and no end of requests for a more succint alternative: https://github.com/dotnet/csharplang/discussions/645 https://github.com/dotnet/csharplang/discussions/645
  - jayd16 5y ago
    I mostly deal with UI code so of course I like it how it is but couldn't anyone create, say, a BackgroundTask<T> that extends Task where ConfigureAwait is defaulted to false? Seems like a clear way to add it to the method signature and inform the caller and solve the issue with minimal work. Does that not work?
    - DaiPlusPlus 5y ago
      That wouldn't be appropriate: whether or not execution should resume on the same context is the caller's responsibility, not that of the function you're calling. i.e. the same async method could be called from UI code and should resume on the UI thread immediately afterwards - or it could be called from library code - the method doesn't know that (nor does the person who wrote the method).
      - jayd16 5y ago
        I see your point but in reality the callee did already make the decision by using Task/TPL. As a language C# leaves the continuation functionality to the specific awaitable implementation. It seems like the natural place to make a different choice. I do agree that I do not want to see it, though.

by jayd16 5y ago

bluquark 5y ago

Kotlin is used to write UI code, and potentially-yielding methods are called with ordinary function call syntax. Kotlin does not have the "await" keyword, but it does have an analogue to the "async" keyword, called "suspend". Here is a post from Kotlin's language designer on their philosophy: https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...

jayd16 5y ago
Kotlin has context blocks instead of the looser context hopping continuation syntax of C# but it seems like it's trading one explicit syntax for another. You can still get off main thread runtime exceptions in Kotlin on Android, so it doesn't solve the issue entirely. I think that just shows how necessary some kind of explicit syntax is, despite all the talk I see that it's unnecessary. I would love to see more examples though, or a Kotlin native UI.
- bluquark 5y ago
  Agreed. The only major language I know of where it's fully implicit is Go, which is rarely used for UI. > I would love to see more examples though, or a Kotlin native UI. Jetpack Compose is a Kotlin-native UI framework. Here are some examples of how it uses coroutines: https://developer.android.com/jetpack/compose/kotlin#coroutines https://developer.android.com/jetpack/compose/kotlin#corouti...

metaltyphoon 5y ago

C# uses “implicit context switch” on its async/await as it captures the current SynchronizationContext by default. On WPF/winforms/UWP and classic ASP there is one, so unless you other wise tell it, the await always comes back on the UI thread. Console and ASP net core have null as their SynchronizationContext.

jayd16 5y ago
C# will not context switch until you yield execution with an await. There is some default continuation setup that will happen if you use the Task Parallel Library (where the context management is explicit but abstracted away inside the library) but that's a different thing.
DaiPlusPlus 5y ago
> it captures the current SynchronizationContext by default. Which results in the majority of async code, which doesn't run in a UI context, needing to spam `.ConfigureAwait(false)` everywhere. It's the most visible wart in C# today - and no end of requests for a more succint alternative: https://github.com/dotnet/csharplang/discussions/645 https://github.com/dotnet/csharplang/discussions/645
- jayd16 5y ago
  I mostly deal with UI code so of course I like it how it is but couldn't anyone create, say, a BackgroundTask<T> that extends Task where ConfigureAwait is defaulted to false? Seems like a clear way to add it to the method signature and inform the caller and solve the issue with minimal work. Does that not work?
  - DaiPlusPlus 5y ago
    That wouldn't be appropriate: whether or not execution should resume on the same context is the caller's responsibility, not that of the function you're calling. i.e. the same async method could be called from UI code and should resume on the UI thread immediately afterwards - or it could be called from library code - the method doesn't know that (nor does the person who wrote the method).
    - jayd16 5y ago
      I see your point but in reality the callee did already make the decision by using Task/TPL. As a language C# leaves the continuation functionality to the specific awaitable implementation. It seems like the natural place to make a different choice. I do agree that I do not want to see it, though.