Forgive me for this, but why is it still called Perl 6?
I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come.
Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant.
So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?
> I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl.
It's both, really. If you use it (and after a while of getting used it), it just feels like perl.
> I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up.
Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
> And the "Perl" brand is still very strong, so we are loath to give it up.
That is great for you as a Perl 6 developer that gets extra attention for the new language by leveraging the Perl brand, but it is absolutely awful for people in the Perl 5 community. Perl 6 gets free press, but Perl 5 gets mocked and public opinion turns even further against it.
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
I know Perl 5 isn't perfect, but no languages are. You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues. I can do everything I need to already, and I can do it really well. I don't need Perl 6, and I won't even consider it until it has a proven track record.
For most people to make the switch, Perl 6 won't need to prove itself as being just better than Perl 5, but it will need to prove itself as the right choice in the full market of languages out there. For at least a few years, and likely many more, Perl 5 will still be the right choice for a lot of work, and Perl 6 will do nothing but confuse people and cause public opinion about Perl and with it Perl 5's market share to sink even further.
> That is great for you as a Perl 6 developer that gets extra attention for the new language by leveraging the Perl brand, but it is absolutely awful for people in the Perl 5 community. Perl 6 gets free press, but Perl 5 gets mocked and public opinion turns even further against it.
First of all, the press for Perl 6 isn't free at all. We get press because we do cool stuff with programming languages. So do the Rust and Nim communities, for example. Please don't downplay our effort. And the comments are full of prejudice against Perl 6 that is rooted in its Perl 5 legacy; so it's not "free" in a second dimension.
Second, in my experience, Perl 6 is only a small part of the ridicule. Mostly it's about Perl being aweful to read (for which Perl 6 bears no blame at all), lousy code quality, unfamiliar looks through sigils, and so on.
> You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues
Have you ever asked yourself if this is actually true? Would your work be much easier if you had sane threading in some scenarios? Subroutine and method signatures? never had to deal with the bloat that comes from different libraries using different object systems?
I also happen to work on big Perl 5 code bases for money, and with the knowledge of what's possible in a perlish language, I regularly identify pain points that in the end are rooted in missing or deficient language features.
Sorry if anything has come off as being too argumentative. I just feel like you are downplaying the large impact that Perl 6 has had on Perl 5 and the public perception of Perl, and the impact that will come when a 1.0 version is officially released. With the new release coming up this may be the last opportunity to avoid the future damage, and that is what my question revolves around. As for everything else, we are really on the same side and I agree with you on the notable points, so I will leave out further discussion.
I am looking forward to the future of Perl 6. I really do like some of the things I've seen going on there, and it is fairly likely that in the future I will be happily writing Perl 6 code on some projects. With that said, I am very concerned about how Perl 6 carrying the Perl name will impact Perl 5, but that is separate from my excitement that a new more modern language will be carrying forward some of the Perl styles.
In short, I do appreciate Perl 6 and I don't mean to downplay anything going on there, but my concern is about what it all means for Perl 5.
Yeah, something like Perl++, Perl 10/Perl X, or something that indicted the scope of the difference in the rewrite would have been nice, though I think it's too late at this point. Ten years ago it would have helped, now 'Perl 6' has been floating around for fifteen years.
I've been in and around Perl for a long time, and this line of argument feels very tired to me.
Perl 6 did not "kill" the Perl brand, the state of Perl circa-2000 "killed" the Perl brand. All the issues @perlgeek just noted, those "killed" the Perl brand. The fact that Python was simply a better option for 99% of the projects that were started around that time (even if half or more went with PHP instead) "killed" the Perl brand.
If Perl 5 as a programming language is so susceptible to "oh but this new version makes it seem that there are deficiencies in the current version", could it be because there are deficiencies in Perl 5? If hiding that fact from others is so important to the "brand of Perl", what does that actually imply?
Please stop pretending that starting a project to build a better Perl somehow killed the camel. It's obvious that this is not true even from a Perl 5 usage standpoint, but it's even more absurd from the standpoint of next year, or the year after...
Please stop pretending that starting a project to build a better Perl somehow killed the camel.
It's easy to look at the rate of change and the timeline of releases of Perl after 2000. It's easy for me to argue that the announcement of P6 (and the promise that 6.0 would be a successor to 5.10 or 5.12) took a lot of momentum from working on Perl.
I suspect, but can't prove without a time machine and a multiverse, that if the "they're sister languages" line of thinking had been in place from the start, Perl could have avoided its lost decade (5.6.0 to 5.10.1).
But Perl 5 is _not_ dead. The camel lives, and has two humps. The "lost decade" cannot be ascribed only to Perl 6. Developers were leaving in droves to newer dynamic languages of the same generation (Python, PHP, and eventually Ruby).
I can agree that it had an influence, but I'm sick of the Perl 5 perspectives that a) the language is flawless and only an idiot would choose something else, b) Perl 6 pointed to flaws which don't exist because hand-waving, Rule A, etc.
Perl 5 has fundamental problems. At first Perl 6 was an attempt to solve those problems without a complete compatability break. That proved impossible, so the scope expanded to be a new Perl.
"But it's painting a bad picture of Perl 5!"
Perl 5 painted it's own picture, I'm sorry to say. The toxicity of p5p, the constant "this language is fine why are you making a new one", the over-confidence that Perl 5 is a pinnacle of how you can design a Perl language... these are Perl 5 things, and they belong to Perl 5. Yet I rarely see Perl 5 programmers owning to these facts.
It's just tired. You yourself did a great job in breathing new life into Perl 5, as part of the Modern Perl movement, which takes as its starting point that Perl 5 allows some seriously flawed programming. Techniques and ideas borrowing from Perl 6 are used to make life easier in Perl 5, developed during the "lost decade".
So, I'm sticking to my position that this whole line of thinking is just tired. For outsiders, Perl 5 was a non-starter because of all the flaws with the language, not because another version was in the pipeline that promised to fix those flaws.
FWIW, I program in Perl 5 every day, and I really enjoy the language.
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades.
I'm wondering which unsolved problems you're referring to in particular. (Surely Perl 5 is not the only language which might happen on problems in upcoming decades, and just as surely Perl 6 isn't immune to them.)
* way too many globals in the language, making any sane threading support very hard
* OO (or lack thereof) in core. Yes, there are nice OO modules out there (Moose/Moo), but it's easy to land in a situation where you have several OO modules in the same project. Also, many built-ins still only deal in strings (example: error messages), not objects.
* lack of proper subroutine signatures. The ones in 5.20 are a step in the right direction, but still far away from anything that the competing languages offer
* high exposure of internals to the XS (C) API make it nearly impossible to do substantial rewrites of the internals
* The regex syntax has been extended way beyond its limits of sane extensibility. Yes, Perl 5 now has named captures, re-usable(ish) subrules and all that neat stuff, but the syntax is so arcane that I have to look it up every single time I use it.
* Poor type system. Perl 5's types (scalar, list, hash, code, type glob) simply aren't enough in world where you have to distinguish binary data and Unicode strings, for example. Or subroutines and methods.
IIRC the new VM (MoarVM) is around for quite a short time and it replaced Parrot in a dramatically short time. What are the advantages of MoarVM over Parrot and why were we stuck at Parrot for so long before giving it up?
I'm the developer of the MoarVM JIT (but not the developer of the MoarVM bytecode specialisation framework, which is typically seen as part of the JIT).
The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
Well, that's a good point, really. The JVM and the CLR do run many (dynamic) languages quite efficiently. On the other hand, that is in no small part due to the man-centuries spent trying to optimise both the JVM JIT and the language-to-JVM compiler.
And as a counter-example, luajit2 was built by one man (mostly) over the course of a few years, and runs very efficiently indeed, in no small part due to the lua-specific choices that have been made.
So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.
Thanks, I think this basic "you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time" is desperately under-appreciated in software architecture
you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time
Ha! My experience with Rakudo was "you go to the developer resources you have, tell them not to change anything, then tell them you're going to throw away their work in favor of something you haven't written yet" and then complain when they leave.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution.
> and why were we stuck at Parrot for so long before giving it up?
Rakudo works on Parrot. Why drop support for it?
Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage.
I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.
> I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago
I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives.
Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?
That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur.
I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?
After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the profiling system (though it went unused). This happened to other people as well.
I've documented this at length elsewhere.
Those specific features we were told explicitly not to work on were on the top of the list of "Reasons Rakudo Must Abandon Parrot". I find that disingenuous, as if Parrot had been set up for failure.
Perhaps I should apply Hanlon's Razor here, but that feels even less charitable.
Ah, we've had this discussion before. No need to rehash it here, I think I was clear before, and I don't see you changing your stance.
I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to inject it into something at best tangentially related, at least lay the foundation so it makes sense when people read it.
I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.
I assume your second whiteknight link was meant to be this[1]. It's interesting comparing his view of Parrot with yours. He may share some feeling with you about Perl 6, but it appears his conclusion about why Parrot didn't work out is quite different. It appears he goes out of his way to explain that Perl 6 did what it had to to get past Parrot's failings:
The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead. After a while I had to ask myself why I was fighting in the weeds so much, when the P6 people were rising above the problems of Parrot and doing things better? If my writing these things wasn’t helping anybody, why bother with it?
Notice that the P6 folks were having their biggest successes when they bypassed Parrot, which isn’t exactly a roadmap for synergy and mutual success.
He goes on to say he doesn't really like Perl 6, and doesn't believe in it's direction or that it can achieve it's goals. That's fine. Nobody has to like everything.
I have to say I agree with his assessment that Parrot's goals have largely been met by multiple other projects at this point. This post has convinced me even more that not relying on Parrot was the right choice, which is sad because I was a big fan for many years. Parrot was a train wreck. Some people think Perl 6 was or still is a train wreck. But that wreck has been making progress, and may actually arrive at the station. Can the same be said of Parrot? Can you really lay all that blame, or even a majority of it on Perl 6? If people wanted to work on Parrot, they would.
What whiteknight didn't say was he'd spent over a year volunteering to port 6model to Parrot and had been repeatedly rebuffed. (He's a much nicer person than I am.) You can find that in the weekly parrotsketch logs too.
Look at the Ohloh logs of contributor activity. You can see them drop right after Rakudo said they were going to abandon the NQP Parrot was using. That's what finally drove people away.
Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness. Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
All I see from that is more evidence for whitenight's theory that separating Parrot and Perl 6 was a major contributing factor to the problems. Instead of one incredibly ambitious project there were two incredibly ambitious projects (possibly half the work of the prior project, but undeniably ambitious) which relied on each other in myriad obvious and hidden ways, in both a technical and social sense.
Looking back on it, it seems obvious they were both doomed, as long as they were locked in that spiral of needing the other to advance to be able to move forward, and not being able to really drive the other project themselves. Think the only way out was to either come together again, not in tighter integration, but as a single project, or to split apart and fulfill their own needs. I think joining was actually the riskier option, there were many people in Parrot with no interest in Perl 6 beyond it's ability to drive Parrot. whitenight is frank and unapologetic in this, as he well should be.
So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot? They were both immature projects, feeling their way through how to proceed. There are countless possible reasons for that, but a big one might be that they were unsure of the continued viability of that implementation, and didn't want to waste weeks of some Parrot dev's time to turn around a week after they finished and say "sorry 'bout that, but 6model really isn't going to work and we're going to scrap it for something else."
Then Perl 6 decides to hedge it's bets on Parrot. Sooner than later, because it was always the idea Perl 6 would run on multiple back-ends. Parrot as it existed could have survived that, if it hadn't already been floundering for a long time. They had recently decided to refocus on Perl 6, after realizing that the whole "VM for everything dynamic" thing wasn't really working, at least not as a main dev goal, and they were desperate for a fix. So what would that have done? Make a situation whose viability could best be described as "ridiculously horrible" all better? The best that could be hoped for there was "still pretty fucking bad."
Whiteknight lays out a pretty compelling case that Parrot was slowly imploding for a very long time. I trust his assessment, as he's one of the few people I recall landing major branches in Parrot, and fairly consistently. I understand that you put a lot of time into Parrot, and also Perl 6. Years. But that doesn't change the fact that many of Parrot's devs decided it wasn't worth continuing. Again, I think whiteknight gives a good explanation; the goals of the project had be mainly met already by outside sources.
Was the situation bad? Undoubtedly, or we wouldn't be having this exchange, but I like to think if you asked people involved from both sides candidly whether or not they thought some blame lied with themselves, they would own up to that.
> Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness.
Rakudo hasn't dropped support for Parrot. Nobody has said that it will. Parrot isn't deal
> Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
Because, as should be obvious to anyone following along, Parrot usually did what it wanted anyway, as evidenced by the planned major shift towards treating Perl 6 as a first class citizen again. You can't shift back to Perl 6 without having shifted away. The stories don't line up. You can't be a controlling prima donna and be sidelined, because being sidelined means a lack of control.
You want to know what this looked like from the outside? Parrot was going downhill for a long time, and when they tried to re-hitch their horse the Perl 6, it was too little too late.
You can reply if you like, and I'll be happy to discuss this with you more here, in this thread, but I think I'm done engaging you on this issue here in the future or elsewhere for the foreseeable future (I imagine you're fine with that). I've spent a lot of time over the years here on this issue with you because you've garnered quite a bit of respect from me due to your prior works, but the way in which you see the people involved in this situation and how you assess their motivations is fundamentally foreign to me. I'm not sure anything I've ever said has actually ever made you think about a single point the issue in a different way than you had before, and if I'm not even having that effect, then I'm not really doing anything worthwhile in these conversations.
So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot?
My problem is that this gets argued both ways. This thread is far too nested anyhow, but here's my complaint.
Yes, Parrot and Rakudo drifted apart. There were poor decisions all around. Patrick and Allison and I in particular talked extensively about how to improve things.
We decided this: I personally volunteered to fix any bug, patch any memory leak, add any feature that Rakudo wanted. I spent a lot of time doing that. Several other people also volunteered to add any feature Rakudo wanted.
Time and time again, we went to the Rakudo developers with proposals and they said "No" or "Not yet". Thus my work was mostly fixing bugs and making minor performance improvements. (The major improvements were in that list. So were major revisions of most parts of Parrot to make it smaller, simpler, and faster.)
Then the NQP rewrite came. Parrot faced using a deprecated NQP for its compiler tools, adopting a deprecated NQP so it would keep working, or rewriting all of its compiler tools.
At that point, I decided that there was no point in working on Parrot and left.
I'll take responsibility for everything I did wrong (or for not doing things I should have done). I don't accept the current party line from Rakudo, however. To wit, "Parrot of course had to be abandoned, because it wasn't meeting Rakudo's needs."
Parrot may or may never have succeeded. Rakudo may or may not have succeeded on Parrot. We'll never know. Yet the claim that Parrot developers weren't interested in making it work with Rakudo is nonsense. In my experience, it was the other way around.
Looking at the release as a whole, I'd be fascinated to hear what features have taken the most time and effort? What turned out to be much harder than expected?
One big challenge is the sweet spot between flexibility and optimizability. Perl 6 is designed for extensibility, and yet we know at compile time where a given subroutine will dispatch to.
Getting the right trade-offs there was no easy task.
Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system.
Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.
I'm also interested in an answer to this question. Perl 6, as a feature set, looks awesome and I'd really consider replacing my use of Python with it, espcially because of the gradual typing and fast startup time (assuming Perl 6 follows Perl 5 in this regard; my initial experiments haven't been encouraging though).
In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, as even Python is showing its age in terms of the programming styles it doesn't support, and has no plans to.
Will it really be released by the end of this year? Obviously the history of this project induces a healthy bit of skepticism. My two cents would be that the dev team should just release it next week and fix the inevitable warts gradually.
On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?
> On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?
I don't think so. Everything I've read in recent years has indicated that the grammar is stable, which implies that the operators and planned feature set are also stable.
If you want to melt your brain, you can take a look at STD.pm6, the official grammar for Perl 6, which is also written in Perl 6:
Just to clarify, as you responded "I don't think so" to two questions, the language is not going to change too significantly prior to release, so yes you should bother learning Perl 6. No one I've met who has actually bother to use the language has had anything but excitement about it.
As always in open source projects, there's the risk that a major contributor might drop out.
Barring that, there are three major technical things we want to tackle before the release: native, shaped arrays (compact storage of arrays/matrices of machine-sized types), the Great List Refactoring (GLR; mostly about speeding up list iteration and making things more consistent), and some Unicode-related tasks.
Any of those might prove more difficult than expected. I personally see the biggest risk in the list refactoring, because lists are rather central to the language as a whole.
Something I've wondered for a while: why was the decision made to write yet another dynamic language VM+JIT (MoarVM) instead of taking advantage of all the work the PyPy folks have done and using PyPy for Perl 6? Was PyPy even evaluated as a possible target?
Why would we want to write Python code to get a new Perl6 backend which doesn't have quite the same object system that Perl6 needs?
At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you )
There are currently 3 backends for the Rakudo implementation of Perl6: Parrot, JVM, and Moar.
The fastest one currently is the one designed to meet the needs of Rakudo: MoarVM. (in many benchmarks) It of course makes sense that a VM designed for Perl6 would work better for Perl6.
Some of the presentations I've seen make it look like MoarVM does some kind of AST specialisation before it gets to the JIT. Is there any documentation of how that works?
* type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path
* inlining
* container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them
* reachability analysis and elimination of allocations are being worked on, iirc.
Do you know who it might be best to talk to about the AST/bytecode specialisation? I work on a compiler with AST specialisations and I'm interested in their approach.
Perl 6 is a spec, and different implementations are possible and encouraged. Rakudo is an implementation, and targets a few different VMs, including Parrot, MoarVM and the JVM. A lot of effort is being put into making MoarVM a good VM for the intermediate language that Rakudo uses to implement Perl 6, but AFAIK the JVM is kept up to date as well, and Parrot is also where time and expertise exist.
Thanks, my intention in asking the question was to see if there is any willingness to speak about what will ship. I don't need a pedantic explanation of the runtimes, I want to know if a decision has been made to get behind one of them. I've been waiting 15 years to hear some actual details about what I can expect when I install this thing.
MoarVM is the closest to "ready", and seems to be what most of the developers actually using Perl 6 today are using. But, as the prior post mentioned, Rakudo-JVM and Rakuda-Parrot are also getting closer to ready. All of them will likely "ship", as long as the developers keep working on them, and Perl 6 code will likely run correctly on any of them.
Note that the Rakudo-MoarVM runtime is the closest to feature complete, with Rakudo-JVM close behind.
In short, you can expect you'll get whichever runtime you install, and if that runtime is ready for production you can expect that Perl 6 will work on that runtime. MoarVM will likely be the first to be ready for production.
You may have other reasons for choosing a runtime; if you have a Java/Clojure/Scala shop and wanted a powerful scripting language to integrate into your systems, the JVM runtime might be just the thing. If you wanted the fastest Perl 6 for standalone Perl 6 applications, MoarVM will likely be it (I think, I haven't looked at benchmarks, just guessing). The FFI may be easier to work with in MoarVM, if you need C or other compiled external libraries...but maybe not. I'm not at all familiar with how that works in JVM runtimes, but it seems like it would be more convoluted.
Why wait? I assume it will be similar to Rakudo Star, which packages[0] Perl 6 for regular consumption on a semi-monthly (quarterly now?) basis, which you can download windows installers for here[1]. If you aren't on windows, compile, it's not that hard, directions are included in the github repo for Rakudo[2] under INSTALL.txt. You can see more info on that at the Rakudo website[3].
0: MSI installers for MoarVM and Parrot, I assume JVM bytecode it includes is in there as it stated it ships with "experimental JVM support."
Most everybody on the #perl6 IRC channel, the central part of the Perl 6 community, is preferring the MoarVM backend. It's only a matter of time and policy until it becomes more "official" in one way or another than the other backends.
It allows arbitrary code to define the subset. So it's very flexible, but it also means that compiler usually can't be clever about subsets. We can't solve the Halting problem for you.
