Hacker News Reader

Comment by JamesSwift | Hacker News Reader

Its async model is a pain point, but otherwise it really does a great job of being able to accommodate a vast range of use cases

View on HN

How so? Practically everything that should be async, can be, and in a straightforward fashion. Biggest pain point was the reliance on generated code that complicated debugging and potentially reduced performance, but this is being addressed in upcoming .NET releases.

It just doesnt generally work how I would expect it to work until you learn the details of how to make it work how you expect. Especially as you get into RX it gets really confusing about which execution context you should be on. And execution contexts in mobile land are pretty convoluted to setup IMO.

So yes "async" is easy, but "multithreaded/parallel" is a lot more error prone and explicit.

EDIT: I should also note I havent been in the space for a few years so Im not fully current on how it looks today

Async carries its own ExecutionContext that crosses threads.

Multi-threaded/parallel is a LOT easier now with the Task Parallel Library (TPL, https://learn.microsoft.com/en-us/dotnet/standard/parallel-p...) and System.Threading.Channels. Channels in particular are nice because it can fan out and then back in to one aggregator, removing the need for self managing synchronization primitives.

I usually default to channels first, TPL when I want threads.

C# async is great. One of the best implementations of cooperative multi threading you can get, IMO.

Greenthreads or what have you are not a replacement if you want to do things like have a UI thread or bind to a native thread for interop. But you _can_ with async/await.

That is the saddest part: there is already a fantastic green thread concurrency for dotnet: hopac. F# then got Task {} and people kind of left hopac behind.

ConcurrentML really brought dotnet's concurrency story into the 1990s.

Reply on news.ycombinator.com