"Colorblind" is an arbitrary goalpost made to satisfy an imprecisely defined term of one blog post.
The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like.
Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for having "color".
"having colors" is an unfortunate property of async/await, not of JS. C# has the same exact set of problems, made even worse by Microsoft's love for horrid APIs and inconsistent runtimes.
You can spawn threads in Python. Async/await is (among other things) a control-flow primitive for single-threaded programs. C# also includes more or less the same async/await as these languages, as far as I know.
Not only do threads not really do the thing (in part because of the high cost of threads compared to alternatives), the alternative isn't only threads. Users of Lua, Greenlet, ucontext_t, libco, etc. have been able to write single-threaded code that's generic over the async-ness of its callees for decades. Recently there's a trend toward preferring needing to change 99 call sites and function signatures when adding a single piece of I/O to a single function though, needing to write two versions of each library, etc.
It seemed like most of your post was about not being able to use the two functions through pointers of the same type, but you can use the two functions through pointers of the same type, so maybe now you can delete a majority of your post and submit a retraction to Hacker News or something.
I'm not sure you are using the same notion of "colorblind" as most people. All that is claimed is that much application code can be *compile time generic* over the async-ness of the I/O functions it calls. Stepping up the requirements to being runtime generic introduces some difficult concerns about the different error sets of different I/O functions, but async vs. non-async can be handled as in the above gist or by writing like one switch statement.
I'm new to Zig this year, and I'll share my own learning experience. ziglang.org's overview[0] says, "Zig functions avoid colors." I interpreted that as similar to Go's lack of function colors. Given the rest of the language design, I didn't think it really possible.
Months later I read Gavin's post (linked above). I found that post immensely helpful to understand Zig's design around sync/async function colors (thanks Gavin!). Gavin's post helped to illuminate for me that Zig functions do have colors, but that the compiler can infer the color in most usual cases. This is still very exciting!
As I see it, it's not to Zig's detriment whether it "has" function colors or not, I don't really care. I'm really excited about Zig either way. But I personally (coming from a decade+ of JS/Python/Go) found the verbiage I found used to describe Zig's behavior here confusing.
My post has three quotes where people claim Zig is completely colorblind, not just at compile-time. My point stands, especially because of the hoops that gist had to jump through to get it to work.
Of course it is. Zig is an up-and-comer, so most established languages will be more popular at this stage. But Zig aims to be a mostly general purpose language (which is what the majority of mainstream languages are), whereas Erlang does not.
Hot-code swapping would guarantee a really fast compile times and maybe even "hot reload" of program while it's running. Do not underestimate how much this helps with developer productivity. I'm so tired of the compile times with large C++ codebases...
Exactly! The idea is during development you use the super fast backend that supports hot code swapping. Then when you want to make a release build you use llvm and get all the optimization benefits of a longer compilation.
* Comptime, which can serve the purpose of generics without a new sub-language [1]
* Colorblind async-await, basically parameterizing async-ness to avoid the downsides of async's infectious nature [2]
* Hot-code swapping proof-of-concept [3] (Edit: specifically, new to low-level languages, AFAICT)
Pretty cool stuff!
[1] https://kristoff.it/blog/what-is-zig-comptime/
[2] https://kristoff.it/blog/zig-colorblind-async-await/
[3] https://www.reddit.com/r/Zig/comments/s9toy1/we_have_a_worki...