What is Production Ready?
Posted: 24/08/2011 Filed under: Perl, thoughts 16 Comments“When will Perl 6 be production ready?” – they ask from time to time. I know the feeling, there was a time I wanted to know too, and after a year working on Rakudo, I can truly say,
I have no freaking idea!
I’d really like to tell you, seriously. If you ask #perl6, they will start tricking you into thinking that it’s ready enough and they’re actually using it, right? Tricky bastards. But, what do you actually ask for? What is this mighty Production Ready?
I dedicated some thinking to this today. What makes something Production Ready? I can think of two possibilities
- The creators declare it Production Ready
- People start using it in Production Environment
The first one is a bit tricky to achieve when it comes to Perl 6. As we know, Perl 6 is a language. How can language be Production Ready? Think, think. Is there another example of something which is rather a spec than an end-user product, and is either not declared as finished, or the spec freeze date is ridiculously far in the future? Right, it’s HTML5. Spec is a draft, it’s nowhere near finished, and neither of the implementation implement all of it. So what makes HTML5 production-ready? I don’t think it’s declared ready by its creators. It’s that people didn’t bother with official opinions and started actually solving problems with it. Took the existing implementations and made use of it. Therefore, we can safely assume that by “Production Ready Perl 6” we really mean “A Perl 6 Compiler I can use to get the job done”. So what are the current compilers lacking for the majority of people?
Yes, I’m asking you. You don’t really know, do you? You didn’t even try them? It’s just that people don’t use them too often, so they’re probably crap, right? Ok, there’s some logic in that.
There is a possibility that Perl 6 is already capable of solving your problems. You should try it. But! Enough of the advertising business, I’m wondering here.
“So what is your Production Ready?”, you may ask. What do I expect from Perl 6 before it will be Production Ready for me? It’s not, I’m not gonna lie. It’s solving my problems, it pays my bills, but it lacks this Something that will make it Purely Awesome. In my opinion, there are two major things we’re missing:
- Speed. Not all things I write need to be blazingly fast, but what is the point of amazingly expressive language, if the bottleneck of the development process is program runtime?
- Access to Perl 5 modules from CPAN. Yes, I know of modules.perl6.org fairly well, believe me. Still, it will take ages, if not infinity to make it as awesome as CPAN is. Blizkost is a bridge between Perl 5 and Parrot and it’s capable of running simple stuff already.
That’s it. I can live without most of the things. But what I’m really looking for, is a better Perl 5. It needs CPAN, and it needs to be less slow that it is. I’m not looking for a C performance. I could live with Perl 5 performance here probably.
That’s what I’m missing. And what is Your Production Ready?
Whatever but Cool 
buf8 support with pack and unpack will be necessary for supporting binary network protocols, like SPDY or WebSockets in Perl6 versus using external libraries, if any in exists for these protocols. Perl 6 must be web ready. The competition is not python or ruby, but node.js
“You should try it.”
I’d like to try it, but can’t get very far without useful documentation. e.g. what’s the Perl 6 equivalent of perldoc -f open ? Where are perlrun, perlfunc etc?
That’d be Synopsis 32 for open(), and rest of the Synopses for the latter two I suppose. Hopefully, what you mention would be possible thanks to my GSoC project, once we are able to document the setting library itself. I agree that we’re missing a proper perldoc, and I’ll think about supplying a proper equivalent.
It’s not ready until O’Reilly publishes a book about perl6.
You mean like “Perl 6 Essentials”, published in 2003?
http://oreilly.com/catalog/9780596004996
Once a Perl6 implementation supports non-blocking IO, it’s likely you’ll see a Mojolicious port; I suspect having a web framework readily available would be a tipping point.
I’m much more tempted to see Mojolicious running on Perl5-Perl6 compatibility bridge, to be honest. Maybe because I don’t expect a Perl 6 Mojolicious port anytime soon :)
There are a few web frameworks for Perl 6. There is one called “Web” which is far from complete, one called “ww6” which is far more complete, but is a bit too convoluted (and that’s high praise, I’m the author of the latter one), and a few others.
When the nom branch has fully replaced the current master (including feature-wise, there are still many things missing) I’m planning on doing a complete overhaul on a few of my Perl 6 libraries, including “ww6”, to make them easier to use.
However, until the speed issues get worked out, it doesn’t matter how many web frameworks there are. Even using SCGI daemons (I wrote the SCGI library too), Perl 6’s speed (at least the Rakudo implementation) is unacceptably slow for live dynamic web applications.
Non-blocking IO? Here you are: https://github.com/tadzik/IO-Select
There are fish in the sea, waiting to be eaten. On the ice pack, there’s a bunch of hungry penguins. They want to jump in and start fishing – but there could be seals in the water, seals that eat penguins. Is it safe? If one of the penguins jumped in, and didn’t get eaten, then all the other penguins would know it was safe, and then they all would jump in. But no one has jumped in. They stand around, looking at each other, hungry, too scared to jump.
Every time someone asks is Perl 6 production ready, it reminds me of those penguins.
If I write code today, will it work on future releases with minimal changes?
If I write code today, is it tied to only one release of one implementation?
If I write code today, can I use libraries with the same guarantees of stability?
If I write code today, am I stuck on a cycle of monthly upgrades, where I have to babysit the code?
If I write code today, will I have to abandon it during yet another compiler rewrite?
CPAN is still “missing”, but I can always write my own CPAN :) Writing my own modules would help me understanding Perl6 better anyway.
I don’t mind the missing features, either. All I wanted from Perl6 is “proper” OO with types, and that’s basically already there.
To me, the only show-stopper is speed. The current implementations of Perl6 are just so incredibly slow that I cannot consider them even for the smallest project. Not even for one-liners. “Fix” that, and I’m an early adopter :)
Chromatic makes good points, because production tends to be associated with return on investment, and a rapidly changing platform means rapidly increasing technical debt/bitrot. However the question of what its production ready can only be answered in fuzzy or subjective and relative terms, and the future is what we choose to make it.
I’m eagerly awaiting the NOM merge, by the sounds it paves the way to solve the speed problem. What I’m looking forward to even more than that is feature stability.
I don’t believe what those tricky Perl6ers say anymore. In more than one way they are too smart for their own good. Otoh, #perl6 is great for mental modeling, so such research is much appreciated. (Keep up the great work, tadzik++)
I use perl 5 for for data analysis, small simulations and prototyping. I’ll switch to perl 6 when it won’t annoy me.
It will annoy me if the wizzy new stuff doesn’t work, or if there are loads of hidden pitfalls that cause scripts to run like a slug.
Well put. I can’t wait to use Perl 6 on my projects.