4 ms·
At least from the Java language advocates' perspective, async/await is a worse solution to the problem of async than the structured concurrency approach that vi
by VagueMag 4y ago
At least from the Java language advocates' perspective, async/await is a worse solution to the problem of async than the structured concurrency approach that virtual threads will enable.
- andrekandre 4y agothats interesting, any good examples?
- VagueMag 4y agoTons of writing and debate on this subject but the canonical starting point is "What Color Is Your Function?" https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- cyberax 4y agoAsync/await are also much slower than properly implemented (see: Golang) fibers. Basically, with async/await you need to allocate on the heap frames for each level of the async/await call stack. You basically get a linked list of stack frames. This is essentially isomorphic to segmented stacks that Go ditched in favor of resizable stacks, because segmented stacks kill performance if a tight loop just happens to cross a segment boundary.
- DeathArrow 4y ago>Async/await are also much slower than properly implemented (see: Golang) fibers. Are there any benchmarks to back that affirmation?
- cyberax 4y agoHm. I know this from my personal work, replacing Go code with an async/await code. There's a bunch of benchmarks that compare C# async/await and Goroutines (e.g. https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11 https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-... ). Go still wins there, but they all miss the very important case of nested async/awaits. These microbenchmarks also focus on looking at Go channels versus other synchronization methods, which in my experience is not that relevant (Go channels just suck). I guess I'll need to write a blog post.
- DeathArrow 4y agoThose benchmarks are really old, things can change quite fast when it comes to programming language implementations.
- cyberax 4y agoI wrote a quick-and-dirty benchmark: https://blog.alex.net/benchmarking-go-and-c-async-await https://blog.alex.net/benchmarking-go-and-c-async-await Results: Go - 32ms, C# - 494ms. The difference also becomes bigger as you add more recursion levels.
- dgb23 4y agoAsync/await proliferates. If you call await, your function must be async too. Green threads are decoupled from synchronization.
- DeathArrow 4y agoYou can use tasks without async/await.
- DeathArrow 4y agoasync/wait is using tasks which are the equivalent of virtual threads. What I do like to see in C# is something akin to goroutines from Go or actors in Elixir.
- shellac 4y agoThis response confuses me since goroutines and Erlang processes are really very similar to project Loom's virtual threads. The mistake is that async/await is not equivalent to virtual threads: the former can do only a subset of what the latter can.
- guiriduro 4y agoVirtual actors for C# are offered by solutions like MS Orleans as I understand it.
- masklinn 4y ago> What I do like to see in C# is something akin to goroutines from Go or actors in Elixir. A task is equivalent to a goroutine.
- DeathArrow 4y agoNot really, see: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11 https://alexyakunin.medium.com/go-vs-c-part-1-goroutines-vs-... https://stackoverflow.com/questions/70501171/are-golang-goroutines-relatively-the-same-as-c-sharp-tasks https://stackoverflow.com/questions/70501171/are-golang-goro...