Is there a reason, why rakudo should target many back ends?

Yes. Diversity in itself is a worthy goal, and there are some technical reasons, like parrot not properly supporting any threading, attracting developers from the target platforms, and interoperation with libraries that run on the alternative target platforms.

Ideally the parrot one should be completed and then it could be ported to other VMs.

What is this "completed" you are talking about? Do you know of any software that is both alive (ie actively developed) and "completed"? Linux is being developed since 1991, and still not completed, and I don't hear any complaints about it targeting multiple platforms.

If you target two more extra back ends its like-time-taken-to-implement-one multiplied by 3.

Only for backend specific code.

If I'm not wrong many such projects already exist eg: Sprixel, Niecza etc.

Neither Sprixel nor Niecza are a Rakudo port to a different platform. They have rather different goals than Rakudo. If we can re-use some of their code, we will. Also, would you care to elaborate on the "etc." part?

Why reinvent the wheel again?

Which wheel do you think are we re-inventing?

... there are some technical reasons, like parrot not properly supporting any threading...

To me, that argues for developer focus on making Parrot support parallelism and concurrency.

Only for backend specific code.

There's the problem, though. Either you write to a bland portability layer which supports the sanest bare-bones intersection of features across every platform to which you eventually want to port (and to have any hope of performance you have huge, platform-specific optimization layers which poke through the bland layer of pudding) or you spend more time porting between platforms and less time sharing code.

If you think you can attract enough black magic developers on these alternate platforms interested in discovering, creating, and maintaining the layers of jiggery-pokery necessary to make Perl 6 perform worth using, your best approach is the pudding layer.

Which wheel do you think are we re-inventing?

Any runtime for Perl 6 is going to end up looking a lot like Parrot.

("My goodness, chromatic! Wouldn't it be easier to port Parrot to these other VMs?" Why yes, yes it would.)

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.

Perl 6 - links to (nearly) everything that is Perl 6.

Ok, whenever this word 'completion' crops up there is great deal of confusion as to what is complete. Complete in the sense Perl 5 is complete. Complete in terms of stability, spec compliance, production readiness, availability of libraries/documentation and usability. Complete not in the sense of halted development. Both Linux and Hurd are being actively developed, but Hurd is not complete in the same sense Linux is complete.

Everything else you mentioned is perfectly acceptable. Probably you can have a second look at the word 'Complete'.

Ok, whenever this word 'completion' crops up there is great deal of confusion as to what is complete.

That's correct. Which is why it's best to avoid it in a discussion about software.

Both Linux and Hurd are being actively developed, but Hurd is not complete in the same sense Linux is complete.

I see only gradual differences. And for a gradual difference it doesn't make sense to say "wait until ..."

Probably you can have a second look at the word 'Complete'.

I just took a second look. It seems half of the explanations there equate "complete" to "dead" if applied to software. So best avoid it.

Don't get me wrong, I don't love to pick on some minor language nits, but if you ask the question again without using words like "completed" or "finished", it will probably come up in a way that makes much more sense, and is much easier to answer in a meaningful way.

Perl 6 - links to (nearly) everything that is Perl 6.

Do you know of any software that is both alive (ie actively developed) and "completed"?

I was going to say TeX, but your sidemark "actively developed" and "completed" are mutually exclusive.

IMO, there's a difference between being "alive" and "actively developed".

Niecza targets the .NET CLR, rakudo aims to target the same in the future(???, Is it so?). What is the difference we are speaking about here? Just the code and the way niecza and rakudo implement them? For the user its the same Perl 6 syntax and semantics running on the same platform.

Is there a reason, why rakudo should target many back ends?

The only worthwhile reason I've heard is "People want to do it." (Targeting multiple backends hurt Pugs more than it helped.)

Diversifying so quickly will slow down an already slow process.

Only if you assume that developer time, interest, and ability are fungible. Porting NQP-rx to .Net may attract people who have no interest in Rakudo on Parrot. Porting NQP-rx to LLVM may attract people who have no interest in Rakudo on the CLR or Parrot. Porting NQP-rx to the JVM may attract Larry Ellison.

Frankly speaking most of the Perl 6 implementations in the Past look like "me too" projects. Start with something just because some body else is doing it, ultimately get overwhelmed by the task and abandon it. This is what fundamentally happens when you want to do it just for sake of wanting to do it. The moment there is some technical barrier the motivation evaporates into thin air.

Apart from a few serious attempts like Parrot, Pugs and Rakudo. Other projects have provided good feedback but that was not the aim of those project, was it?

Focus is the name of the game for large projects like this. Parrot wanted to be a good runtime for Perl 6 but what did it end up being? Run time for a near dozen languages but slow with a suboptimal GC. Now Rakudo wanted to run on Parrot but is now aiming to run couple of other backends. The focus keeps dividing and ultimately time passes on and nothing worth while is achieved. People get frustrated and find something else no matter how much you try convince them.

It's not difficult to imagine all successful projects in the open source community example Linux, Perl, Python started as small humble projects but scaled over a period over the time. Alas, that never came to happen with Perl 6. One very large ever evolving spec, with implementations constantly loosing focus and jumping anything new on the market. Will we have to wait for another 10 years while this comes out clean,or never?

I keep wondering why such views are almost always expressed by Anonymous Monks? They can't be bothered to sign up to Perl Monks? They can't personally stand up for their views? Are they total outsiders who just come by bashing or have they had any real contribution to any of the related projects?