What problem is there beyond that?
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.)
