I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases.
For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
Which means that you can't be a system programming language (for some definition of system programming).
You don't want to use blocking mutexes anyway with async.
or Rust's Rc
This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.
FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
Comments
I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases.
For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
Which means that you can't be a system programming language (for some definition of system programming).
By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
You don't want to use blocking mutexes anyway with async.
This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.
FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
A simple call to https://pkg.go.dev/runtime#LockOSThread solves that.
Pay the cost of backwards compat when you need it, don't pay it when you don't need it.