In a couple of important places Rakudo really stalled in the last half of 2011 due to the unfortunate absence of pmichaud++, its 'pumpking'. Jnthn++ and moritz++ have been able to recover some of the lost territory, but I'd say there's been almost a 50% drop-off in the rate of overall progress. I'm afraid the bus number is too low for expectations to be too high.
So there are now three Perl runtimes/compilers/interpreters--Rakudo (+ Parrot VM), Niecza (CLR), Perlito (?)--none of which yet implements the full Perl 6 spec? (Which itself is not yet complete, although "2011 was a rather quiet year in terms of spec changes.")
I'm trying to think of a way to read your question that doesn't make it dismissive and condescending. Why wouldn't the current three implementations be angled for real-world use?
I'm using Perl 6 "in the real world". I use it on my spare time. I use it at work. I have production code running in Perl 6. I use Perl 5 even more heavily, but with each month I use Perl 5 a little less and Perl 6 a little more.
"Why wouldn't the current three implementations be angled for real-world use?"
Because going to perl.org -> Download says "We recommend that you always run the latest stable version, currently 5.14.2." [1] and doesn't even mention Perl 6.
And when you do find a page that has Perl 6, it says "If you are looking for production ready code please use Perl 5" [2]
When somebody asks you "What's the latest version of C?" Do you answer "C++11"? Of course not.
Perl 5 and Perl 6 are two different languages that happen to share a similar style and history. The latest version of Perl5 will never be 6.something.
And yes, Perl6 is not recommended for production use, since the specification has not been finalized. By the same argument, C++0x should not have been, yet many people did.
As a comparison, python.org has both Python 2 and Python 3 binaries clearly marked and available for download.
I'll be surprised if Perl 6 gets much attention until the perl.org download page has links to Perl 6 binaries, like it does for Perl 5 binaries. Visiting the download page, you wouldn't even know Perl 6 exists.
By the same argument, C++0x should not have been, yet many people did.
I see little equivalence; despite the flux of the C++0x specification, many C++ useful and usable compilers existed and implemented several portions of the specification.
Put another way, the draft status of portions of the Perl 6 specification say nothing about whether "Just compile git HEAD yourself!" is the preferred distribution and deployment mechanism, nor about whether the right approach to supporting real users involves slapping a TODO tag on regressions to appease the test suite.
... many [Perl 6] useful and usable compilers exist and implement several portions of the specification.
My company was working on a product based on Perl 6 two years ago. We planned to release it to paying customers at the time of the Rakudo Star release. We officially scuttled it several weeks ago when it became obvious that Rakudo's development process would continue to be incompatible with shipping a working product for as far as we could predict (and two of us have commit access to most or all of the Rakudo stack, so it's not like we're disconnected from the development of Perl 6).
The words "useful" and "usable" do not reflect the reality of the situation.
Could you explain what happened to change your perspective?
Certainly. Rakudo Star wasn't what everyone hoped it would be, but I figured another few months of tuning and releases would let it stabilize to the point where our customers could rely on it as a significant part of the product. That was my understanding of Rakudo Star, sort of the Perl 6 version of Debian Testing versus the Debian Unstable monthly compiler releases.
Performance wasn't a huge concern; the five to ten percent monthly improvements we were getting were sufficient for our projections, if they continued. (They did.)
Around December 2010, some of the Rakudo discussion turned to rewriting the main implementation language used to bootstrap Rakudo (and part of the discussion was "Hey, this'll be a great opportunity to consider targeting additional backend VMs!"). Scopes creep and rewrites produce regressions and remove stability.
Rakudo forked its development into "The old stuff that used to be Rakudo Star but won't get any updates or even releases" and "The new branch which will become the main branch even though it won't see any releases and has huge regressions" and they're starting to address regressions now.
As you might expect, the release schedule for Rakudo Star slipped from "every month" to "every three months" to "whenever things get stable".
In the absence of project discipline to release stable code every month--in a culture which believes it's okay to tell people "Sure, it's useful and usable, just track Git HEAD for multiple components"--you can't deploy a product without heroics. I'm not going to risk my business on heroics.
In short, they stopped delivering a stable product and I stopped believing in their ability or their desire to do so.
As an outside observer of Perl 6 development since its conception, I feel that this pattern (Scope creep and massive rewrites / depreciation of current infrastructure whenever one component was in "danger" of becoming useful) has played out over and over again throughout the life of the project.
This went back at least to the original Parrot announcement. Arguably, even the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding the much more modest Topaz effort (After about two years of development, Topaz had not yet delivered fully working code. The original announcement of Perl 6 promised working code in 18 months).
Parrot and Perl 6 really suffered until Pugs started producing a standalone test suite. If Perl 6 on Parrot had had that in 2000 or 2001, things might have turned out differently.
I normally agree that throwing away working code and starting anew is the wrong approach, but trying to rewrite the Perl 5 internals to support Perl 6 would have taken at least as long as Parrot and Rakudo have taken; it's really that impenetrable in places.
Your phrase "in danger of becoming useful" is quite perceptive though; I wish I'd thought of it.
I love perl6, and though I wish otherwise, I have to agree with this assessment. #perl6 is a resonant echo chamber, but I do admire the people and enjoy reading the logs. Maybe one day...
I am very interested in Perl 6. What would be the recommended implementation to use in production? What are your experiences with using it in production?
I've been an active Perl 6 user since 2008; during that time, I've often had too high expectations on then-current Rakudo implementations: I've been dabbling in wiki software, etc. It was slow. Sometimes it was unstable.
Seen from ten thousand meters, Rakudo 2008-2010 was about features, and Rakudo 2011 has been about performance. As moritz' retrospective states, the fruits of that work are only coming online now. That will enable more people to move into performance-sensitive fields such as web development with Perl 6. That's already starting to happen; see tadzik's Bailador project, for example.
Meanwhile, my Perl 6 production code has been getting by with slightly lowered expectations on performance and memory frugality. Crashes/segfaults are no longer a problem (as they were in 2008/2009). Tradeoff example: My blog, which runs on Perl 6, is statically generated rather than dynamically. That's been working out pretty nicely.
When I need more speed and/or regex/grammar features, I go with Niecza. Otherwise, I mostly develop on Rakudo. But Niecza's main developer is developing at an almost intimidating pace, and I expect to be using Niecza even more in 2012.
"real world" means different things for different people.
At this point how many companies do you know of that use perl6 to solve their business problem (may be as simple as a web app) ?. Has there been any job posting anywhere which are looking for perl6 devs?
That said, there's two of us in the company I work for: http://www.edument.se/english/ . I got hired mostly on my merits as a Perl 6 core contributor. We're eager to hire more Perl 6 programmers.
The good thing about perl 6 is that lots of ideas from there are getting back into perl 5 and believe it or not Haskell got a bit of a boost because of perl 6 (when the pugs project was in full swing).
Even if one of the projects implements the full perl 6 spec that exists today, there are very few perl 5 devs that will switch over ,If I were asked to guess it would be less than 5 %. Perl 6 as a language has to start at the bottom with other programming languages . The name perl6 was used because one of the reason (I am not sure of this) was to retain the name to get perl5 devs to move to the next version of the language and at that time perl5 was a dominant language.
Another perspective to look at is that perl6 was announced in early 2000 clojure came around 2007 , scala appeared around 2003. There are other languages like go and dart which have google backing that have come out.
So IMHO if you want to learn language design and the other things around it perl6 is a good playground you will learn and easy to get into the community but you will not get a job because of it. If you are a user of programming language who wants to use a language for solving a real world problem today (with libraries and get questions answered) or learn a language which will get you a job you will be better off with perl5 , php, ruby, python, scala, clojure or <insert your lang>
Back in the day, I was an avid mod_perl user and Perl 5 enthusiast.
I recall being optimistic that Perl 6 would come out of the oven in 12 to 18 months. Sadly, that was in 2004. My feelings about Perl 6 are like those about a Microsoft OS that is stable, secure and performant: a nice idea that has grown into a myth. Sorry to dump on Perl, I still have many friends who use Perl 5 on daily basis. I think for a lot of folks, the real "Perl 6" is... Ruby.
A "ruby vs. perl" fight is the furthest from my mind, I'm just speaking anecdotally about what my friends who, like me, were heavy perl users are using in it's place now. If the "measurably" bit refers to how the runtimes benchmark, yes, absolutely, it doesn't make sense.
