jnthn decided Perl 6 on JVM was the quickest way to get Perl 6How quick?
First, how quick it would be isn't really important. If there's already one acceptable VM, and the project is late, then no matter how quick a port would be, it's almost certainly the wrong thing to do. Conversely, if there is NOT already one acceptable VM, and the project is late, then the right thing to do is almost certainly to get an acceptable VM done as fast as possible, no matter how long that takes.
Second, it's only of historical interest how quick the JVM port was. It's done. That's why, in the last few weeks, as just one example of the impact of freeing Rakudo Perl 6 from Parrot, the critically important concurrency and async parts of 6.0.0 that have been delayed by years have started landing. (To acclaim by at least some of the P5ers that have seen it.)
There are plenty of other important things like the standard library, CPAN compatibility and documentation to be sorted out and standardized before we branch out to other platforms.
It's pointless having doc, standard libs, and CPAN compatibility if it doesn't run acceptably on ANY platform. To be clear, this is by no means just about concurrency, async, and parallelism, or even speed. Simple buffered IO in Rakudo Perl 6 has fallen victim to a series of basic bugs in the last 12 months, bugs that have taken months to resolve, partly because Parrot contribution has been drying up since 2010.
Perl 6 has to run acceptably on ONE platform. Perl 5 has an acceptable platform. Perl 6 did not. (You might think that Parrot is/was acceptable, but have you actually checked that assumption out?)
I too think that the JVM might well be fine as the one platform for rolling out 6.0.0. It was partly chosen because it was about the shortest route to a VM that would let the team drive Perl 6 and the Rakudo compiler toward 6.0.0, but it was also chosen because it's a production worthy VM. It might work out as the sole VM for an initial official 6.0.0 roll out.
That said, the NQP/JVM backend currently has a few fundamental weaknesses as a Perl 6 platform (eg it takes several seconds to start). While the JVM solves immediate problems Rakudo had, allowing Perl 6 and Rakudo to move toward 6.0.0, there's still a chance it will turn out not to be acceptable to many as a mainstream production VM.
Some devs who did not do significant work on Rakudo, and who would not write doc or Perl 6 library code, wanted to work on a VM. Are you suggesting they should have been told to go away, maybe to work on, say, a Python VM instead? Regardless, they were not told to go away, and they're now building out a VM that generally uses one quarter of the RAM that the JVM does (so half the RAM Parrot does), starts thousands of times faster, implements 6model and NFG natively to great effect, and so on.
In reply to Re^7: MoarVM update
by raiph
in thread MoarVM update
by raiph
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |