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".