Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Chromatic: Goodnight, Parrot
Posted Feb 10, 2013 17:08 UTC (Sun) by rahulsundaram (subscriber, #21946)
If someone could fill in the rest of us on what this means for the future of Perl 6, it would be good to know.
Posted Feb 11, 2013 18:23 UTC (Mon) by raiph (guest, #89283)
Rakudo is the leading Perl 6 compiler. Imo, at least in the short term (2013), where Rakudo goes, Perl 6 goes.
1. Getting to Rakudo on JVM
* First, I recommend folk consider reading the outstanding blog post rahulsundaram linked.
* http://pmichaud.com/2012/pres/yapcna-perflt/slides/slide3... is a slide from a fun 5 minute lightning talk (video at http://pmthium.com/2012/09/a-rakudo-performance/). This slide shows the ratios of the four languages used to implement the Rakudo compiler: Perl 6, NQP (a mini Perl 6), C, and PIR (Parrot Intermediate Representation) code. The sliver of PIR is a few weeks from being driven to zero.
* Once the NQP port to JVM is done the Rakudo Perl 6 compiler can be ported (jnthn clearly expects the whole Rakudo to be ported by yapcna, Austin TX, June 3-5.).
2. What Rakudo on the JVM means for Rakudo
* As http://perl6.org/compilers/features shows, Rakudo is deficient on Unicode and related items, native types, and threads. (It's arguably ahead of Perl 5 on all three of these, but it's deficient relative to the Perl 6 spec.) Rakudo devs claim these had been held up by problems related to Parrot and that the JVM will provide a suitable backend to get these functionality pieces nailed down. Note that JVM functionality that enabled completion of the Perl 6 spec and Rakudo implementation, not speed, was the primary reason for porting to the JVM.
* Larry Wall recently said that speed is the #1 blocker of mass adoption of Perl 6. Although Rakudo has recently closed the speed gap in most regards compared to Niecza (another Perl 6 compiler that targets .NET) it's still dog slow in many ways. However, there are reasons to believe Rakudo on the JVM may be faster, perhaps an order or two magnitude faster, than Parrot. (chromatic seems to dispute this.) Imo, if Rakudo substantially speeds up it will be a game changer.
3. What a fast, complete Rakudo will mean for Perl 6
Larry recently said he hopes to publish a Perl 6 equivalent of "Programming Perl" (the bible for Perl 5) around the end of this year. In mid 2009 I predicted Perl 6 would reach a generally robust state around the end of 2014. I think I was about right and folk will begin adopting Perl 6 in earnest during late 2014 or early 2015.
Goodbye, duct tape
Posted Feb 12, 2013 0:10 UTC (Tue) by man_ls (guest, #15091)
There are many other languages that run exclusively on the JVM, but they are mostly esoteric -- the most popular of those seems to be Scala.
There are other issues like memory usage and startup time. Perl5 used to be the duct tape of the internet; requiring a JVM for Perl6 will make it unfit for that particular purpose (which for me is filled nicely by Python 2 anyway).
Posted Feb 12, 2013 1:18 UTC (Tue) by raiph (guest, #89283)
Huh? Perl 6 has never depended and will never depend on anything proprietary.
Just because you can install non-free device drivers on a Linux system does not mean Linux is now suddenly dependent on that non-free software. It just means the Linux developers have not gone out of their way to stop people doing what they want to do.
> There are other issues like memory usage and startup time.
Indeed. The 2013 focus on speed and memory is needed. But, as even the originally very skeptical dskoll specifically recognized in this thread with a "wow" after he acually tried it again, Rakudo is improving on about the pace the devs suggested it would around 2 years ago.
Having it both ways
Posted Feb 12, 2013 11:32 UTC (Tue) by man_ls (guest, #15091)
Given that there isn't a single official runtime, I see a maze with just dead ends and proprietary options. It is like the situation with Linux a few years ago when graphics drivers were either unusable or proprietary; the community worked on it and now we have very good free drivers for popular boards. Is the Perl6 community similarly worried, or happy with the situation?
Posted Feb 12, 2013 12:03 UTC (Tue) by epa (subscriber, #39769)
Posted Feb 12, 2013 13:50 UTC (Tue) by raiph (guest, #89283)
Posted Feb 12, 2013 2:31 UTC (Tue) by wahern (subscriber, #37304)
A nice JVM is http://jamvm.sourceforge.net/. It's not the gargantuan, unportable mess that other JVMs are, which typically aim for speed first and sanity later.
Something like JamVM should also be quick to start up, too. But I completely agree that common JVMs suck for general scripting tasks. Solaris, I believe, tries to optimize this by sharing JVM instances. But "scripts" which require the JVM are still dog-slow.
Posted Feb 12, 2013 2:33 UTC (Tue) by wahern (subscriber, #37304)
Posted Feb 12, 2013 11:37 UTC (Tue) by man_ls (guest, #15091)
Posted Feb 12, 2013 14:00 UTC (Tue) by raiph (guest, #89283)
As jnthn recently said:
"The way Perl 6 progresses in terms of its language design is thanks to people using the bits of it that are implemented so far and providing feedback. While a great deal of the language spec is now very stable, that has come after a great deal of feedback. We’ve some areas where we’ve not been able to build and try out certain things on Parrot, a big one being concurrency. Parrot lacked any kind of threads for years, and what it has now is not a great basis for building much on, sadly. That still leaves aside async operations, which should be considered in with all of this. Meanwhile, the JVM can offer well tested, widely used, battle-hardened building blocks for looking into these things, which will allow us to focus on the Perl 6 aspects of things without having to worry (much) about hitting VM bugs."
Once the JVM port is done I've no doubt that ports to other backends will start landing, and I've no doubt most will be non-proprietary.
Posted Feb 13, 2013 19:34 UTC (Wed) by wahern (subscriber, #37304)
However, it implements an older spec of the JVM, v2 instead of "Java SE 7 Edition" (i.e. v3). But if you just want a nice, portable JVM, it's a good target, or at least a good place to start.
Posted Feb 11, 2013 17:20 UTC (Mon) by raiph (guest, #89283)
Posted Feb 12, 2013 3:01 UTC (Tue) by raiph (guest, #89283)
(He's spent years thinking about portability issues and otherwise preparing for ports to VMs other than Parrot and I'm sure that'll be going on as he completes the JVM port.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds