3 ms·

Why didn’t C# or JS go this way?

balfirevic 6y ago
For JS, cynical take would be that Javascript is just being consistent in making every wrong choice in language design. More serious (and more correct) answer is that, being single-threaded, adding any kind of threads would be pretty adventurous. Async/await as a sugar for promises is a decent improvement over using promises directly, so it's not so bad of a choice after all. As for C#, some kind of fibers appear to have been considered but deemed too hard or not worth the trade-offs. See here: https://github.com/dotnet/runtime/issues/11084 https://github.com/dotnet/runtime/issues/11084 The acceptable alternative was, apparently, forcing to programmers to litter their code with words such as async/await/task in-between the words and symbols that actually describe the purpose of their program, should they want to take advantage of non-blocking IO. All the way throughout the call-stack, nonetheless. And you also get crap like this: https://github.com/dotnet/corefx/pull/4868 https://github.com/dotnet/corefx/pull/4868
- int_19h 6y ago
  Win32 has fibers, which are essentially green threads. And for a while, .NET itself tried to support it. The problem is that there was never widespread support on the native side of things, and in .NET itself, user code has to not make certain assumptions to allow for fibers to work (e.g. that each managed thread maps 1:1 to an OS thread), which in practice nobody followed. This points at the bigger problem that every implementation of green threads has: it breaks interop unless everybody buys into it. Async/await is fundamentally callback-based, which can be represented nicely even in C ABI - so literally any language that can interop with C, can interop with an async/await model, with execution flow asynchronous throughout the entire chain. Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime.
  - balfirevic 6y ago
    Win32 fibers would probably not be a good match for potential .NET fibers. From the link in my previous comment, they seem to allocate the stack of the same size as regular OS threads, making them not appropriate for the use case of keeping thousands or more fibers around. > Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime. You'd still be able to interop with async code outside of runtime, you can still model the API as callbacks for the interop purposes where needed. But yes, interop has sam trade-offs. Which are, IMO, entirely correct trade-offs to make for Go, Java and .NET (and overwhelmingly so). But they are probably not for (as an example) Rust, according to it's goals.
    - int_19h 6y ago
      They're definitely not correct for .NET - you forget WinRT. That ecosystem was much more heavily invested in native interop from the get go - COM interop, P/Invoke, various runtime features like unmanaged pointers and unions etc. So once native async became a thing, .NET developers expect to be able to interop with it, as well.

For JS, cynical take would be that Javascript is just being consistent in making every wrong choice in language design. More serious (and more correct) answer is that, being single-threaded, adding any kind of threads would be pretty adventurous. Async/await as a sugar for promises is a decent improvement over using promises directly, so it's not so bad of a choice after all. As for C#, some kind of fibers appear to have been considered but deemed too hard or not worth the trade-offs. See here: https://github.com/dotnet/runtime/issues/11084 https://github.com/dotnet/runtime/issues/11084 The acceptable alternative was, apparently, forcing to programmers to litter their code with words such as async/await/task in-between the words and symbols that actually describe the purpose of their program, should they want to take advantage of non-blocking IO. All the way throughout the call-stack, nonetheless. And you also get crap like this: https://github.com/dotnet/corefx/pull/4868 https://github.com/dotnet/corefx/pull/4868

int_19h 6y ago
Win32 has fibers, which are essentially green threads. And for a while, .NET itself tried to support it. The problem is that there was never widespread support on the native side of things, and in .NET itself, user code has to not make certain assumptions to allow for fibers to work (e.g. that each managed thread maps 1:1 to an OS thread), which in practice nobody followed. This points at the bigger problem that every implementation of green threads has: it breaks interop unless everybody buys into it. Async/await is fundamentally callback-based, which can be represented nicely even in C ABI - so literally any language that can interop with C, can interop with an async/await model, with execution flow asynchronous throughout the entire chain. Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime.
- balfirevic 6y ago
  Win32 fibers would probably not be a good match for potential .NET fibers. From the link in my previous comment, they seem to allocate the stack of the same size as regular OS threads, making them not appropriate for the use case of keeping thousands or more fibers around. > Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime. You'd still be able to interop with async code outside of runtime, you can still model the API as callbacks for the interop purposes where needed. But yes, interop has sam trade-offs. Which are, IMO, entirely correct trade-offs to make for Go, Java and .NET (and overwhelmingly so). But they are probably not for (as an example) Rust, according to it's goals.
  - int_19h 6y ago
    They're definitely not correct for .NET - you forget WinRT. That ecosystem was much more heavily invested in native interop from the get go - COM interop, P/Invoke, various runtime features like unmanaged pointers and unions etc. So once native async became a thing, .NET developers expect to be able to interop with it, as well.