zlacker

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.

>>vlovic+(OP)
There's no function colouring in Go. Async functions don't have any special colour.

>>vlovic+(OP)
Go doesn't have function coloring. Greenlet, Lua, and libco solve the problem without function coloring by adding a stack-switching primitive. Zig solves the problem without forcing function coloring on all consumers of functions by having the compiler monomorphize functions based on whether they end up being able to suspend.

>>vlovic+(OP)
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.

>>anonym+Wh
A more accurate description would be that Go has a single function color, that is namely green. This distinction is important because, for example, C also has no function coloring problem only because it doesn't care about lightweight threading, i.e. its function color is always red. Only Zig's approach, and hopefully Rust's keyword generics if accepted, can be considered to have no function color.

>>lifthr+tl
I don’t understand the difference between "single color" and "no color", can you explain? What makes Zig’s approach colorless?

>>thiht+7z
While the original use of "function colors" was purely syntactic [1], they can be easily remapped to cooperative vs. preemptitive multitasking. This remapping is important because they change programmer's mental model.

For example, the common form of `await` calls implies cooperative multitasking and people will have a good reason to believe that no other tasks can't affect your code between two `await` calls. This is not generally true (e.g. Rust), but is indeed true for some languages like JS. Now consider two variants of JS, where both had `await` removed but one retains cooperative multitasking and another allows preemptitive tasks. They will necessarily demand different mental models, even though it is no longer syntactically distinguishable. I believe this distinction is important enough that they still have to be considered to have a function color, which is only uniform within a single language.

Zig's approach in comparison is often called "color-blind", because while it provides `async` and `await`, those keywords only change the return type to a promise (Zig term: async frame) and do not guarantee that it will do anything different. Instead, users are given the switch so that most libraries are expected to work equally well regardless of that switch. You can alternatively think this as follows: all Zig modules are implicitly parametrized via an implicit `io_mode` parameter, which affect the meaning of `async` and `await` and propagate to nested dependencies. There is definitely a color here, but it's no longer a function color because functions can no longer paint themselves. So I think it's reasonable to call this to have no function color.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

>>lifthr+dB
Interesting thinking, thanks for the details! I’ll have to look into Zig’s async mode, it seems pretty good but I’m wondering what are the drawbacks of this approach (and specifically, why would you ever set io_mode to "sync")

>>lifthr+tl
Last time I checked Zig still had a subtle form function coloring for function pointers. See for example https://github.com/ziglang/zig/issues/8907

>>yawara+yh
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)

>>SkiFir+h11
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.

>>gpdere+UV1
What is the difference between a sync and an async function for you then?

>>SkiFir+3w2
An async function is on CPS form and return it's result via a return continuation. Typically when invoked from a non CPS function it also forks the thread of execution.

These days async functions are also typically lazily evaluated via partial evaluation and the return continuation is not necessarily provided at the call site.

A sync function provides it's result via the normal return path.

>>SkiFir+h11
Go works fine for C FFI, all of its problems there are caused by its innovation wrt dynamic stack sizes and having a garbage collector. I'd rather write multithreaded Go FFI than deal with JNI again, anyway. There isn't really a language keyword-level concept of async in Go that's comparable to `await` in JS, or Java futures, or Rust async.

>>thiht+QM
This post is a bit confused. io_mode is an stdlib feature that changes some blocking stuff in the stdlib to use the stdlib's event loop. There's not such a thing for most libraries.

For typical libraries, functions and structs are provided, and to the extent that these functions call functions provided by the user, they are generic over the async-ness of those functions. That's how the language-level async feature works, for library code that doesn't specify that it is async and doesn't specify that it would like to use a specific non-async calling convention for calling the user's callbacks.

>>SkiFir+h11
> IMO saying there's no function coloring in a language ignores a lot of details.

Details which are meant to be ignored. When you use async/await constructs in various languages, you don't care about the fact that they are desugared into callback chains under the hood. You either do async/await in a language or you don't. That's what the concept of 'your function has a colour' means. If you want to change the meaning, OK but then you're talking about something else.