In the interests of decorum, I've changed my mind about that.

How tacky.

Parrot's current lead dev has a starkly different opinion

Christoph is Parrot's current leader, not Andrew. While I agree that Parrot needs 6model (and 6model is an improvement over the previous object system), the reality is far, far more complicated than Andrew makes it sound.

In particular, Parrot adopting 6model wholesale even last year (as most of us wanted) would have been highly difficult because 6model was still in flux, because Parrot still had to support a lot of abandoned Rakudo tools which relied on the old semantics, and because Jonathan was dragging his feet on helping Parrot adopt 6model.

Note that he mentions "targetting backends" *last*.

You've changed your argument from "He rarely or never mentions it" to "He mentions it last in a list which isn't obviously ordered in terms of descending priority."

jnthn frequently mentions NQP and almost never mentions how it'll help in porting to other VM backends or that it minimizes Parrot exposure.

Read 6guts.

We need to focus as much effort as we can to be a better VM for Rakudo Perl6, including moving as much custom code from the NQP and Rakudo repos as possible into Parrot core to lower barriers and increase integration.

I've fixed enough of the custom code in Rakudo that I feel confident in saying that big wad of code was a big part of the problem.

The point of Rakudo Star was and is to be a bundle of bits -- latest compiler, modules, etc. -- that were/are sufficiently "usable and useful for early adopters"...

My business had a product to release based on Rakudo Star two years ago. (We were preparing to ship it in April 2010.) We had customers ready to pay for that project.

We never shipped that product because Rakudo Star was neither usable nor useful for our purposes. It still isn't.

If I were a betting man, I'd bet Perl 6 will be productized over the next year or two.

Rakudo Star was supposed to be a product two years ago. That was the point of Rakudo Star. It's still not a product now.

... it's important to note that the reason it was introduced, and is being developed, has little to do with a desire to have a VM abstraction layer.

... except for the fact that almost every time its lead developer talks about it, he talks about how it'll help porting to other VM backends (and that it explicitly exists to minimize the amount of Parrot surface area exposed to Rakudo).

In fact, the Parrot (VM) team plans to backport NQP to Parrot.

I think you're confused. The Rakudo team has written at least three things called NQP and all of them run on Parrot. In fact, that's one of the biggest problems of Rakudo: writing code that Parrot has to support and then abandoning it and complaining that Parrot can't move fast enough for Rakudo because Parrot has to support Rakudo's abandoned tools.

Imo it's very likely the Rakudo team will make this level of integration work reasonably well this year.

On what do you base this opinion? Rakudo's had more than one proof of concept that never made it much past the proof of concept stage before bitrotting before.

It's not secret that a substantial amount of Rakudo development goes toward writing something intended to be a VM abstraction layer. The official party line is "To improve the potential of running on other VM backends".

Perl is very cumbersome in this regard.

It can be, yes. The last two times I needed multiprocessing, I used Proc::Fork and WWW::Curl::Simple. These worked very well for me.

A lot of people use AnyEvent quite effectively too.

... what widely used "new" project in the last five years has chosen Perl?

I've deployed a few projects in the last five years. I know many people who've also deployed projects.