Value Semantics and async code
What does Mojo's value semantics mean for writing asynchronous code? Can Mojo sidestep the problem of coloured functions, or make it easier to write asynchronous code?
4 Replies
Function color is still present here, and an effects system is not on the roadmap, so you'll likely have to deal with some of the same friction points on that you'd remember from rust
I'd say the jury is still out on function color. If we can find a good way to avoid color, we will. But as of today, there is no agreement that it can be avoided.
Well, for example, race conditions only occur in asynchronous code, but value semantics would prevent race conditions right? So do you think that value semantics makes asynchronous code less complex and easier to write in general?
Mojo can do proper multi-threading, unlike Python, so it would be capable of racing in sync code if not for the lifetime checker, which prevents race conditions altogether. 100% pure value semantics is like 100% pure functional programming, it works, but is VERY slow, so it's better to have 90% value semantics like Mojo does and have raw pointers as an escape hatch. It's the combination of value semantics and lifetime management which make Mojo have safe async.
I'd say that Mojo's async will be harder to make something the runs than Python or C++ coroutines, but easier to make correct. Essentially, all of that time debugging race conditions is pushed to designing your application and "convincing" the compiler, but once you make it compile there are no race conditions.