Yes, unlike the languages mentioned in TFA, it just works. Specifically, you can `await` anywhere without the requirement of declaring the surrounding context as async which in practice means you eliminate the red/blue distinction.
It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled.
I think the main problem has been that it requires building an appropriate concurrency design into the foundation of a language.
For most PLs, concurrency is somewhat of an afterthought, and even for those where concurrency was addressed from the get go, the design nevertheless doesn't support work stealing, or, if it does, doesn't support doing so at the language level.
> I doubt...
Scepticism is healthy. :)
But regardless of my speculation about why most PLs don't go this route:
* The general technique (called "work stealing"[0]) was first implemented last century;
* PLs can support it directly at the language level provided they have suitable foundations;
* Raku is one such PL.
The first version of Raku (Raku Christmas, released Christmas Day 2015) already eliminated the need for function colouring. While the first version included an array of concurrency, async, and parallel processing features, including an `await` keyword, there has never been an `async` keyword in Raku. This is unusual, but Raku is not the only recently released PL to do so.
Work stealing semantics for `await` were only formally introduced in Raku Diwali, released Diwali day 2018, and the corresponding Rakudo compiler. Again, this makes Raku unusual, but not unique.
(What is perhaps unique is that Raku programs can include both old and new semantics in the same program. Raku has a radically different take on language evolution and backwards compatibility such that incompatible changes don't mean modules are incompatible with each other. Not easy to do, but possible, as demonstrated by Raku programs that make use of both Christmas and Diwali modules.)
> Sounds pretty easy, no?
It is easy for users. Once it's implemented in a language.
But it's not easy for language designers and implementers. (And it's essentially impossible to introduce if a PL has already adopted older approaches to concurrency.)
That is your opinion. Mine is that it is okay to "sow doubt", similar to that it is okay to "sow doubt" when someone claims they built a perpetuum mobile.
But since you are asking me to download the language so politely: I think this is not necessary. A look in the documentation (https://docs.raku.org/language/concurrency) seems to be enough:
> The subroutine await is almost equivalent to calling result on the promise object returned by start but it will also take a list of promises and return the result of each
So "await" is equivalent to calling "result". What does calling "result" do?
> result blocks the current thread of execution until the promise is kept or broken
This stands in direct contradiction to what was said in the thread here:
> so while the code containing the `await` blocks and waits, the underlying thread/core is released
Unless the OP referred to a _different_ await, I would say: case closed.
I think Java does have coloured functions. It's just that the colours are "fast" and "slow" - i.e. functions which will block the thread for a long time and those which don't.
You can't call "functions that may block for a long time" from a UI thread. Java doesn't have async, so you have to punt them to a background thread manually.
Not sure why I’m getting downvoted? The linked article goes at length saying callback hell is terrible, await is a partial solution, and languages that are free to use threads have it best. Author upholds that, “Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate.”
I don't know why you got downvoted. Then again, I'm not quite sure what you meant by "await is a partial solution" and "languages that are free to use threads have it best".
As far as your quote goes, I'll add:
> Or, more precisely: multiple independent callstacks that can be switched between. It isn’t strictly necessary for them to be operating system threads.
(Quoting the same paragraph you quoted.)
Standard Raku provides support for OS threads; green threads; coroutines; multiple independent callstacks that can be switched between; an `await` that doesn't require function coloring and is cooperative, supporting work stealing of its thread when it's waiting; multiple other constructs for concurrency, multiple others for asynchrony, multiple others for parallelism; and is an extensible PL anyway.
If you could briefly put your comment into that context, so that I (and perhaps other later readers) could better understand it, that would be helpful to me. I plan to upvote both your above comment and any below if what you're saying then makes sense to me. TIA if you have time to reply.