zlacker

[return to "The bane of my existence: Supporting both async and sync code in Rust"]
1. toolto+sh[view] [source] 2024-01-19 23:36:57
>>lukast+(OP)
The comment threads here discuss async in many different languages: Rust, Go, JavaScript, Python. Can somebody knowledgeable describe how they are subtly different between languages? Why are they painful in some but not in others?

Is there already an article that describes this well?

◧◩
2. vlovic+jj[view] [source] 2024-01-19 23:49:54
>>toolto+sh
They’re painful in all contexts because of function coloring. They’re slightly less painful in Go and JS because there’s a single opinionated async runtime built in. In Rust they have yet to standardize a bunch of stuff that would remove the pain:

async traits in std instead of each runtime having their own,

a pluggable interface so that async in code doesn’t have to specify what runtime it’s being built against

potentially an effect system to make different effects composable more easily (eg error effects + async effects) without needing to duplicate code to accomplish composition

Keyword generics as the current thing being explored instead of an effect system to support composition of effects

With these fixes async rust will get less annoying but it’s slow difficult work.

◧◩◪
3. pcwalt+yE[view] [source] 2024-01-20 03:24:28
>>vlovic+jj
For Go I'd say there's a single synchronous runtime built-in. People say that Go is async because the implementation of goroutines is async internally, but the implementation of threads on every OS is async internally too. The only real difference as far as sync/async is concerned† between goroutines and threads is that Go's implementation of goroutines is in userspace, while the implementation of OS threads is in kernel space. Both are equally asynchronous under the hood.

† Yes, there are other differences between goroutines and typical OS threads, such as stack sizes, but I'm only talking about I/O differences here.

[go to top]