Hacker News new | ask | show | jobs
by masak 5281 days ago
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.

3 comments

"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]

[1] http://www.perl.org/get.html

[2]http://dev.perl.org/perl6/

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.

True, but there's no "5" in "perl.org".

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.

Despite the flux of the Perl6 specification, many Perl6 useful and usable compilers exist and implement several portions of the specification.
... 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.

This is rather surprising, coming from you. In past years, you vehemently took the opposite side of that argument (e.g. http://news.ycombinator.com/item?id=1737504).

Could you explain what happened to change your perspective?

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.

Niecza sounds like it's coming along nicely but I'm not interested in relying on Mono or .NET.

Is there a Perl 6 implementation for any other free VM's (aside from Parrot)? I've heard Lua's is very fast. Or maybe LLVM?

"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?

No, it's still too early for that.

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.