To me, that argues for developer focus on making Parrot support parallelism and concurrency.
I'd love that, but I don't see it happening.
Consider tt #757. It's an absolute show stopper for having threads in Rakudo, to the best of my knowledge. It has been open for 14 month. For about a year it has had a patch. Nobody applied it.
Why?
It's not the question of awareness - I've mentioned that patch at several parrotsketch meetings, and asked for review. No reaction.
My conclusion is that none of the core developers has the sufficient mixture of time, motivation, focus, skills and understanding of the code base and the issue to review the patch.
I haven't seen any indication that this is about to change. I also hate to go shouting on the mailing list and say "go focus on threads", because I know that other areas in parrot require just as much attention, probably more.
Any runtime for Perl 6 is going to end up looking a lot like Parrot.
Citation needed.
I can also assure you that any runtime for Perl 6 is going to end up looking very much different from the parrot we know today. It will need a garbage collector that doesn't switch off when we switch on threading. It will need a cross-platform JIT compiler. It will need to be installed into paths that contain spaces.
Parrot is moving in that direction, and so are other VMs. Lots of things have changed in the world of virtual machines since parrot has started to fly.
That said, we certainly don't plan to abandon parrot.
In reply to Re^4: Backend diversity for Rakudo
by moritz
in thread Backend diversity for Rakudo
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |