3 ms·

I don't think there are really ways to do async programming that don't have gotchas. It's just inherently complicated. And of course C#/.NET is a bit older and

I don't think there are really ways to do async programming that don't have gotchas. It's just inherently complicated. And of course C#/.NET is a bit older and also very large, it has more surface area for weird behaviour that might not be easily fixable due to backwards compatibility. Things like using void as a return type for an async function can be a nasty surprise if you're new, but this is not an issue at all once you know this (or if you simply used the right examples and used Task from the start). It's not a subtle gotcha. Sync over async is much sneakier and can be very nasty. But I'm not sure you can avoid this when interacting with a language/environment that used to be mostly sync and switched to async. If everything is async you don't have this issue, so this is better for newer codebases.

only_as_i_fall 5y ago
Sure, but I'd argue that the best way to handle this is to just stick to the already existing paradigms that developers have experience with. It's not like there are any problems which can't be solved without async or tpl, and it's not like Microsoft wants to introduce a similar paradigm outside of the .net ecosystem, so it's just creating an artificial barrier and making the code harder to understand so that they can post clean looking examples on their doc pages.
- contextfree 5y ago
  JavaScript/TypeScript and C++ do implement a similar paradigm, loosely patterned on what C# does?
  - ziml77 5y ago
    Python and Rust as well. C# invented a large part of the design of async/await that has been adopted by other languages. I figure if there's a better way, it would have been improved on by now since those other languages had plenty of time to see the issues with C#'s version.
    - metaltyphoon 5y ago
      Most claimed “simpler” languages are only being used for backend systems, i.e go, BEAM languages. There’s a reason that any language where UI needs to be considered has used what C# has. The flow of code is simplified because you don’t want to be on callback hell.

only_as_i_fall 5y ago

Sure, but I'd argue that the best way to handle this is to just stick to the already existing paradigms that developers have experience with. It's not like there are any problems which can't be solved without async or tpl, and it's not like Microsoft wants to introduce a similar paradigm outside of the .net ecosystem, so it's just creating an artificial barrier and making the code harder to understand so that they can post clean looking examples on their doc pages.

contextfree 5y ago
JavaScript/TypeScript and C++ do implement a similar paradigm, loosely patterned on what C# does?
- ziml77 5y ago
  Python and Rust as well. C# invented a large part of the design of async/await that has been adopted by other languages. I figure if there's a better way, it would have been improved on by now since those other languages had plenty of time to see the issues with C#'s version.
  - metaltyphoon 5y ago
    Most claimed “simpler” languages are only being used for backend systems, i.e go, BEAM languages. There’s a reason that any language where UI needs to be considered has used what C# has. The flow of code is simplified because you don’t want to be on callback hell.