Asynchronous Programming in C# • Hacker News Board

Re: Asynchronous Programming in C#

#131

Post by metaltyphoon » Fri, Sep 24, 2021, 8:08 PM UTC

ziml77 wrote: post #119

contextfree wrote: post #105

Earlier quoted context omitted.

JavaScript/TypeScript and C++ do implement a similar paradigm, loosely patterned on what C# does?

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.

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.

Re: Asynchronous Programming in C#

#132

Post by phamilton » Fri, Sep 24, 2021, 8:26 PM UTC

Jtsummers wrote: post #79

gambler wrote: post #72

Earlier quoted context omitted.

In short, they provide clean API for checking on completion and error states of a long-running process from another thread without blocking that thread. This is an essential pattern for UI-related tasks, including web pages.

Fair enough, I think we are thinking of futures slightly differently. I was thinking primarily about the deferred action to get a result (in which case channels and goroutines are equivalent with a select to handle, perhaps, an error result). You're also thinking of the other capabilities around task management and monitoring which I was not.

An easy example of where having promises is nice:

  a := getFoo()
  b := getBar()
  c := getBaz()

If you want to do all 3 in parallel, you may need to use channels and wait groups and stuff. In a language with promises:

  const a = getFoo();
  const b = getBar();
  const c = getBaz();

  await a
  await b
  await c

or even better

  const [a,b,c] = await Promise.all([getFoo(), getBar(), getBaz()])

If/when go generics become available, I expect to see some libraries that make things easier in golang.

Re: Asynchronous Programming in C#

#133

Post by [deleted] » Fri, Sep 24, 2021, 8:31 PM UTC

ridiculous_fish wrote: post #43

Why do we need the `async` keyword? What is the difference between a function which returns a Task , and an async function which returns a Task ?

[deleted]

Re: Asynchronous Programming in C#

#134

Post by [deleted] » Fri, Sep 24, 2021, 8:38 PM UTC

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

[deleted]

Re: Asynchronous Programming in C#

#135

Post by throwaway13337 » Fri, Sep 24, 2021, 8:41 PM UTC

async/await makes things complicated - this is a great illustration of some issues with it. Fibers/green threads/goroutines seem to be generally easier and not viral. C#/dotnet choosing this the async model always bothered me. Otherwise, the platform is solid.

It's interesting, therefore, to try to understand why dotnet went with the async/await model.

A language maintainer C# talks about the issue here and references the rust justification for the same:

https://mail.mozilla.org/pipermail/rust-dev/2013-November/00...

https://github.com/dotnet/runtime/issues/11084

They knowingly seem to have chosen a more complicated model for performance. For me, that sounds like a bad trade. Developer time is quite a bit more valuable than compute time. The performance difference just doesn't seem to justify it.

Re: Asynchronous Programming in C#

#136

Post by Zababa » Fri, Sep 24, 2021, 8:48 PM UTC

Jenk wrote: post #129

Zababa wrote: post #120

Earlier quoted context omitted.

How is .NET fighting against JavaScript or Python? Java or Go, I can understand but not JavaScript or Python.

Serverless computing is dominated by node, go, and python. .NET just doesn't startup fast enough.

Good point, I didn't think about that.

Re: Asynchronous Programming in C#

#137

Post by lazulicurio » Fri, Sep 24, 2021, 8:50 PM UTC

UglyToad wrote: post #91

lazulicurio wrote: post #63

Earlier quoted context omitted.

The way I put it: .NET async makes the easy things easier and the hard things harder. The problem is that Task/Task was the foundation for async, and it's a bad foundation. Even with the ability to write your own duck-typed awaiters (and the advent of ValueTask), the widespread use of Task means if you're writing async code you're going to have a tough time getting away from it.

I think this is the crux of the matter. Since Task and the TPL predated async, iirc, people get befuddled by the parallelism Vs concurrency (if that's the correct term) parts of the Task API. Certainly the async story is a lot more complicated in desktop but it is very simple for most server scenarios, simply put "use this async call so that the thread can do other things while you wait for the db to respond" and the…

IMO it's more fundamental than the parallelism v concurrency split.

Microsoft in general has a tendency to bolt on functionality in a kinda slapdash manner when another team wants it, so you get a lot of cruft that really doesn't belong in the Task class[1] but is there because someone wanted a way to handle their special case so it just got thrown into Task.

[1] See https://source.dot.net/#System.Private.CoreLib/Task.cs,045a7...

Re: Asynchronous Programming in C#

#138

Post by dpix » Fri, Sep 24, 2021, 8:52 PM UTC

Been a few years now since I've worked much in C# but these all seem like things that should be linting rules.

Can these be added as warnings to the compiler? Can you have custom lint/compiler warnings from the community like eslint?

Re: Asynchronous Programming in C#

#139

Post by binarynate » Fri, Sep 24, 2021, 9:17 PM UTC

I use C# primarily for Unity, and the part about avoiding async void caught me off guard. So, I tested it out and found that in Unity, throwing an exception from an async void method doesn't crash the process. So, it seems that the advice about avoiding async void is specific to ASP.NET.

Re: Asynchronous Programming in C#

#140

Post by _old_dude_ » Fri, Sep 24, 2021, 9:23 PM UTC

throwaway13337 wrote: post #135

async/await makes things complicated - this is a great illustration of some issues with it. Fibers/green threads/goroutines seem to be generally easier and not viral. C#/dotnet choosing this the async model always bothered me. Otherwise, the platform is solid. It's interesting, therefore, to try to understand why dotnet went with the async/await model. A language maintainer C# talks about the issue here and reference…

Implementing coroutine requires to change to the code generator, the runtime and the garbage collectors and there is no general consensus on the way to implement them efficiently => this requires a huge investment in engineering.

For Rust, one of the feature of Rust is to have a minimal runtime, so using a compiler transformation seems a good fit.

For C#, Microsoft has a limited number of people working on the runtime of DotNet. Async/await was developed at the same time DotNet was transitioning to DotNet Core which also requires massive engineering, so it was about priority. The future will tell if at some point coroutine will be added to DotNet.