Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want.
They look far too similar to the many other similar Perl 6 failures we've seen.
How are we to trust that Rakudo won't go the way of Pugs, or that MoarVM won't go the way of Parrot, leaving us in a lurch?
Even if they do remain viable, we don't want to have to deal with separate VMs, regardless of whether they're specific to Perl 6 or not.
We don't want to deal with the bugs and compatibility issues that invariably pop up when dealing with separate compilers and VMs.
Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience.
We want there to be one consistent implementation that's widely used and trusted.
We want something proven and familiar.
Unfortunately, we aren't getting that with Rakudo and MoarVM, nor from the many other unsuccessful attempts in the past.
Why not? A core implementation with its own VM (MRI+YARV for Ruby from 1.9 on, for instance) seems to be pretty common for languages.
> Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience.
But that's exactly what Rakudo + MoarVM offers. For the Ruby comparison, Rakudo is analogous to MRI, MoarVM is analogous to YARV.
> We want there to be one consistent implementation that's widely used and trusted.
And why can't Rakudo be that implementation?
> We want something proven and familiar.
Well, clearly, it won't be proven till its been around for a while in production use, and won't be familiar till you've used it for a while. But I don't see any reason that Rakudo (which is used for some things exposed to the public now) can't be the thing that ends up "proven and familiar"?
> Unfortunately, we aren't getting that with Rakudo and MoarVM
In what concrete way is that true?
Rakudo + MoarVM is going to be "it" going forward I would think. I guess we'll wait and see. That doesn't mean that other compilers won't come along because that is one of the benefits of Perl 6. All the languages you mention have different versions out there. The only one that doesn't is Perl 5 and that's because only Perl can parse Perl. That's going away with Perl 6 and that's good. Rakudo+MoarVM is great. It still leaves the door open for genius to shine.
Rakudo + MoarVM is exactly what potential Perl 6 developers want. Everything else is just gravy.
I have no idea if Perl 6 will "take off". I hope it gains traction. Watching Larry Wall got me interested enough to install it and start learning it anyway.
Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by yet another marketing announcement.
One can hope that development focus will then switch from semantics to things like stability, deployment and performance, ie the things you strongly advocated for years ago.
I guess we'll see if it's going to happen that way...
Given the reception to the past year's worth of discussion around "Get ready to party", it seems irresponsible to me to continue with these semantic distinctions, as they're lost on the intended audience.
There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C.
It's the Python implementation that pretty much all Python developers and users happily and successfully use.
Then there are the experimental or niche Python implementations. They augment very specific and isolated use cases, instead of splintering and delaying the adoption of the language like the many failed partial Perl 6 implementations did.
It should be evident that the Python approach is better than the Perl approach. We've been able to use Python 3 in production for many years now, while Perl 6 still isn't usable.
You've got MoarVM, which is just like CPython But if you want a different backend - great! Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting). For example, use JVM, just like Jython.
This is a stark difference to the situation of Perl 5, where there is only one interpreter, and there's little, if any chance of another. There's no Perl 5 language specification (as there is in Perl 6), except the Perl 5 interpreter. Only Perl 5 can parse Perl 5.
Perl 6 got so many things right, it's phenomenal.
Getting things right takes time, and it only happened because so many things went wrong.
This historical revisionism continues to be tiresome.
I'm historian of Perl 6, a bit :-). http://www.slideshare.net/michaljurosz1/perl-family-15-years...
Open source, volunteers, real life, ecosystem, not easy to implement so feature rich language, ... this wasn't planned.
For 99% users "Perl 6" will mean just "Rakudo + MoarVM" which seems to be exactly what you're asking for.
Note that MoarVM is nothing like Parrot. Parrot was a failed project which intended to bring universal VM for all dynamic languages. Obviously, too wide project scope resulted in broken and unmaintainable implementation.
MoarVM is made just for Perl 6 and intends to avoid repeating its predecessor's mistakes.