It's obvious from the examples provided in the post. For example, you can use the method `URI.open` both synchronously and asynchronously.
It's something I didn't want to mention in the article because it's a relatively advanced async concept, but yea - Async Ruby is already colorless and it's great.
> Async Ruby is colorless!
I find it deeply irritating that this is how we choose to describe things these days. Rather than talking about modality, or even using a few more words to describe the actual differences in terms of the underlying programing language models.
Telling me that Ruby's async is colorless implies that I know about the description of programming models as "colors" of code, which was just some random analogy someone came up with which caught on. Nothing about this has anything to do with color. Even syntax highlighting doesn't really fit. This is akin to particle physicists getting cheeky and calling one of the quantum states "color" when it has nothing to do with wavelength (correct me if I'm wrong).
This is an appeal to stop trying to be so cute. Thank you.
"coloring" goes back before a few blog posts, it was probably popularized with programmers that keep up with crypto, as 'colored coins' are described in an influential paper right around the creation of Ethereum (Vitalik is one of the authors)[0], but I found some earlier references too, like coloring a complex plot to add a dimension [1], so carrying it over to computer programming, you have functions that have otherwise identical signature that you need to distinguish, so you make them different colors.
[0] https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTC...!
https://softwareengineering.stackexchange.com/questions/1166...
Colored = Promise<T>
Colorless = T
In "colorless" async/await, async functions are implicit (no async keyword), and when called, the compiler auto-unwraps the promise, so everything looks like "sync" code but any function stack could "save and resume" at an "async point".
No, I don't think there's anything fundamentally different.
Ruby 3.0 implements a "fiber scheduler" feature that enables "colorless Async". Fiber scheduler is an obscure Ruby feature, but the end result is brilliant. It was also a huge amount of work.
Side note: Fiber scheduler was implemented by the same guy who created Async Ruby - Samuel Williams. This guy is the mastermind (and master-coder) behind this project.
Ruby async seems to be implemented using stackful coroutines. IIRC Guido has been opposed to adding these to core Python, preferring stack-less coroutines because they require every yield-point to be explicit (i.e. marked with `await`).
There are libraries for a python that support stackful coroutines, such as gevent.
And I think I've come to the conclusion that any re-usable code I write for IO should just be written async with magic sync wrappers for use in sync contexts.
[0] https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2....
https://gist.github.com/coezbek/07061fb7de2b036bf5c69f8a8b8c...
I might be using it wrong...
That's pretty magical. Does this mean it would be possible to implement structured concurrency [0], but without the function coloring problem?
Regardless, I think I prefer how this looks from a code read/writeability perspective compared to Zig's or Swift's (and potentially future Rust's [2]) approaches.
[0] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[1] https://kristoff.it/blog/zig-colorblind-async-await/
[2] https://blog.yoshuawuyts.com/async-overloading/