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. yawara+RA[view] [source] 2024-01-20 02:41:51
>>vlovic+jj
There's no function colouring in Go. Async functions don't have any special colour.
◧◩◪◨
4. SkiFir+Ak1[view] [source] 2024-01-20 12:22:42
>>yawara+RA
IMO saying there's no function coloring in a language ignores a lot of details.

In Go there's no function coloring because there are only async functions. That's why they don't get any special color, they are the only color. In Go you don't get to use sync functions, which creates problems e.g. when you need to use FFI, because the C ABI is the exact opposite and doesn't have function coloring because it only allows you to use sync functions.

Zig and Rust's async-generic initiative are a bit different in that they want to allow functions to be both sync and async at the same time. Ultimately there are still colors, but you don't have to choose one of them when you write a function. However IMO there are a lot of non-trivial problems to solve to get to that result.

Ultimately Go's approach work well enough, and usually better than other approaches, until you need to do FFI or you need to produce a binary without a runtime (e.g. if you need to program a microcontroller)

◧◩◪◨⬒
5. gpdere+df2[view] [source] 2024-01-20 18:11:47
>>SkiFir+Ak1
That's a bit of nonsense. As far as I know, all functions are sync in go. The fact that they are implemented async in the runtime with an user-space scheduler is irrelevant (you could otherwise make the point that there are truly no sync functions).

If we call the go programming model async, the word has completely lost all meanings.

[go to top]