3 ms·

Rust has std and async_std as separate codebases because of function coloring. Zig has the same codebase that supports both evented I/O and blocking I/O because

Rust has std and async_std as separate codebases because of function coloring. Zig has the same codebase that supports both evented I/O and blocking I/O because of the non-existence of function coloring. Zig has the same codebase with regards to allocation as well; there is no "allocator_std" or some nonsense like that. Where is the paradox, exactly?

steveklabnik 6y ago
> Rust has std and async_std as separate codebases because of function coloring. It depends on what you mean by "separate codebases." asyc_std is a third party package someone made, so it's a separate codebase because of that. We could also include all of it (or something like it) and it would be a "single codebase," but I think that's more about your wording than your point.
littlestymaar 6y ago
Hi Andrew, I'm a big fan of your work btw. As I said in the original comment, sync/async and no-alloc/alloc or no-error/error are in a parallel situation. And in a language design you can either expose “colors” to your users, or hide it through some magic and a global state. I personally prefer the former, and I liked Zig's idea to expose the allocation explicitly, instead of what Rust did initially (there are slowly rolling out the option to use a specific allocator for collections, which is good even if it took almost 6 years after 1.0). With error Handling, Zig also took the same route with error sets instead of exceptions. That's why I don't think the colorblind async mechanism is a good fit in the language (and it adds some cognitive burden, because newcomers need to learn that looking at code full of async/await doesn't necessarily mean they are looking at non-blocking code). (Also, async-std is a third party library with little in common with std and whose name has been chosen for “marketing” reason, so I' don't really think the comparison is relevant.)

steveklabnik 6y ago

> Rust has std and async_std as separate codebases because of function coloring. It depends on what you mean by "separate codebases." asyc_std is a third party package someone made, so it's a separate codebase because of that. We could also include all of it (or something like it) and it would be a "single codebase," but I think that's more about your wording than your point.

littlestymaar 6y ago

Hi Andrew, I'm a big fan of your work btw. As I said in the original comment, sync/async and no-alloc/alloc or no-error/error are in a parallel situation. And in a language design you can either expose “colors” to your users, or hide it through some magic and a global state. I personally prefer the former, and I liked Zig's idea to expose the allocation explicitly, instead of what Rust did initially (there are slowly rolling out the option to use a specific allocator for collections, which is good even if it took almost 6 years after 1.0). With error Handling, Zig also took the same route with error sets instead of exceptions. That's why I don't think the colorblind async mechanism is a good fit in the language (and it adds some cognitive burden, because newcomers need to learn that looking at code full of async/await doesn't necessarily mean they are looking at non-blocking code). (Also, async-std is a third party library with little in common with std and whose name has been chosen for “marketing” reason, so I' don't really think the comparison is relevant.)