Christmas Came, Bah Humbug
Perl 6 is here and people in the Perl community seem to be excited, but I don’t understand why. Perl 6 is a bit sexier than Perl 5. It’s got quite a few whiz-bangs I’d like to use. However, I’m likely never going to use it, and I think the same is true for the other established businesses using Perl 5. Here’s why:
There is no real migration path from Perl 5 to Perl 6. If you have any significant code base in Perl 5 you’re going to keep working in Perl 5.
If you decide to up and rewrite your entire system, are you going to choose Perl 6? As amazing as Perl 6 is, I don’t think so. I think you’re going to pick Javascript and node.js. The reason is simple, Javascript has a lot of the same flexibility as Perl, it’s faster than Perl, and there’s an almost immeasurable amount of work being put into Javascript libraries.
I’ve always said, much to the dismay of my Perl community compatriots, that developers go where the jobs are. If there aren’t businesses adopting Perl 6 in a major way, it will be a major failure. So now the question is, how do you compel a new business, or an old business writing a new app to use Perl 6 instead of Perl 5 or Javascript? I’ve been searching for the answer myself as a business owner. I want to love Perl 6, but I can’t find a business case for it.
[From my blog.]
My little part in the greater Perl world.
As I stated in my London Perl Workshop Keynote, this is just the End of the Beginning.
I agree that for Perl 6 to take off, there needs to be a business case for it. In 2016 we will see mostly optimizations being applied to the MoarVM/Rakudo code base. I'm convinced we will be able to get to execution speed comparable with Perl 5 in 2016, and surpass Perl 5 in many cases.
As for current reasons that may already be faster:
These may not be your business cases, but I know they are business cases for *some* people already.
Meanwhile, you might be interested in reading Why should I learn Perl 6? What's so great about it?.
Thanks for the comment Liz.
The reasons you cite are good technical reasons, but they aren't business reasons.
Business reasons to stick with Perl 5:
Enertia: It works. It does what I want, the code is already written it it, my developers know it. Therefore it costs me nothing to switch.
Support: CPAN has a huge library of modules that allow me to connect to virtually anything and read and write virtually any file type. Therefore my developers can implement things faster and have less to maintain.
Business reasons to adopt Javascript on a rewrite rather than Perl 6:
Cool: The community of developers out there think Javascript and node.js is cooler than Perl, because Perl 6 comes with the baggage people think they know about Perl 5. Therefore it is easier to hire Javascript devs.
Support: There is an enormous library list for Javascript out there these days and it grows geometrically. Therefore my developers can implement things faster and have less to maintain.
Async: Perl 6 is probably on equal ground here, and maybe even better, but Javascript is definitely way better at async than Perl 5. And the async features of Javascript are fairly well understood, whereas Perl 6 has to educate folks about its features. The business case for async is that I can scale further with less hardware. That allows my engineers to manage less hardware, and me to buy less hardware.
Front/back: When doing web apps, Javascript works front and back end. That means that there can be some shared libraries for things like input validation, as well as shared language knowledge between the front and back end developers. As a business that means less bugs, less duplication of effort, and more shared expertise amongst my staff.
For Perl 6, the only business case I have been able to come up with is if the business happens to absolutely need one of Perl 6's killer features, like grammars. Otherwise, even though it may be technically superior to other languages for things like float math, it is generally easy enough to work around those limitations in other languages if they have enough other good business cases.
I cannot give you an immediate business case to switch to Perl 6, but I can address some of your points.
Perl 6 has the module Inline::Perl5 that allows you to use virtually all code from Perl 5 inside Perl 6. Almost all your code plus almost all those modules in CPAN can therefore be used in a new project in Perl 6. If you don't want to rewrite all your code, this allows for any smooth transition you would like to have.
In addition to that, there's Inline::Perl6 for Perl 5, so you can use any Perl 6 program you want inside your Perl 5 programs.
Inline::Python for Perl 6 adds to this. Using C code in Perl 6 is easier than it is in Perl 5.
Work on Inline::Ruby and Inline::Lua (both for Perl 6) is in progress.
Work on javascript as a virtual machine for Perl 6 is also in progress, which, when done, would allow Perl 6 to be executed in the browser.
The modules directory for Perl 6 ( https://modules.perl6.org/ ) is growing, I was surprised to see that it is nearing 500 modules. I know, it's nothing compared to the more than 150,000 modules on CPAN, but (again) they can be used via Inline::Perl5.
It is possible to upload and download Perl 6 modules to CPAN (thanks to Andreas Koenig and others). There are still some problems (big problem: after downloading, the installation does not work yet, darn), but this is one of the things that will be fixed in 2016.
Maybe not a business case. But to call it humbug is not what I consider fair. A lot of work was done, and more will be done. At least have an open mind, play around with some of the nifty things, try to have fun, and maybe a business case will come to you.
"Async: Perl 6 is probably on equal ground here, and maybe even better, but Javascript is definitely way better at async than Perl 5."
It's true that Javascript and Perl 6 both have significant advantages in built-in async support. In particular Perl 6 has real threading built-in, unlike Perl 5's interpreter threads which should mostly be ignored, but that does not mean Perl 5 is incapable when it comes to async. Once you add in the CPAN libraries you mentioned earlier, Perl 5 has multiple quite nice async frameworks to choose from, all with extensive ecosystems and lots of work toward optimization and practicality. While POE has been around the longest and may not seem very Javascripty, IO::Async and Mojo::IOLoop tend to work much more like Javascript async; there's also Future and similar libraries which implement Promises, and so on. And other than AnyEvent the async frameworks are generally cooperative with each other.
I know a lot of people have put a ton of time into Perl6, so its hard to hear it when people say, "so what?" I have to be honest and say that I've felt increasingly unhappy with how all this ended up, but I really, really want to be constructive and useful here so I will just try to outline concerns I've heard and felt for the purpose of trying to figure out where to go from here.
I think JT is correct in saying most companies using Perl5 are going to pass on Perl6 unless a better migration path is laid out. Most of the companies I've worked for the past 10 years thought of their Perl5 code as embarrassing legacies that caused a ton of trouble (can't hire enough Perl5 programmers, etc.) So once you are talking about porting the code, they are immediately thinking, "Why not ditch this Perl junk that everyone under 40 hates?" Thats something to overcome.
I know Inline::Perl5 exists but until someone ports a real world, significant application with it, and shows the performance isn't abysmal that road is a non starter. So I really hope we can do something here, like port some well known Perl5 application (like maybe Bugzilla or something) to run under Inline::Perl5. Some sort of white paper thing. And there has to be some value like "and its 10 times faster!". What is the reason to do that that is awesome and cool, beyond "I get to use Perl6?" Because that is just not enough.
As someone using Perl5 for about 20 years and feeling like I know it pretty well, I find Perl6 not straightforward to learn. After playing with it last week it feels to me like its going to be easier to learn Javascript or some other language that has better documentation, and actually has jobs. So that is something we need to figure out how to overcome.
At my current job I heard some interest in Perl6 running on the Java VM so that is definitely something to focus on. The JVM has a lot of backing.
Compiling Perl6 to Javascript to run in the browser I think is a waste of time. Front end UI Javascript types tend to be the ones that look down on Perl the most, and they are not going to have a good reason to choose Perl6 over ES7 or Typescript if they want that. HOWEVER there might be some value to this to get Perl6 code running in places that only run Javascript, like Amazon Lambda I think must be Javascript on Node.js. The browser thing is a neat demo but letting me write Perl code and target systems like AWS Lambda that only take Javascript would be interesting and valuable. Its the kind of think that would make a Perl5 programmer think twice about Perl6 (IMHO)
Perl6 has a lot to overcome. You have to placate all the Perl5 programmers that have spent the last 15 years explaining to their bosses that Perl5 wasn't dead because Perl6 wasn't finished. And who after looking at Perl6 come to the conclusion that its an entirely new language and that all the Perl5 ability we've built up are not really applicably (or no more so than learning another language that people like and have available jobs, and a future).
You also have to show why Perl6 is so much cooler than existing stuff that its something worth putting up with all the missing bits (great docs, jobs, etc.) Larry said he thought people would write PhD dissertations on Perl6. I'd like to know what about. What is so amazing about Perl6, what is an order of magnitude better than other options? Other languages have clear 'elevator' pitches. Javascript is everywhere, easy to learn and has very very fast compilers with all the features people expect in a modern language. Java is rock solid. And so forth. The Advent stuff was interesting but nothing blew me away. Remember, people don't change for 10% better. Maybe other people feel differently?
Also it wouldn't hurt if a major company using Perl5 made a very public commitment to Perl6. Stuff like that is very important. Right now if my boss asks me what companies are using Perl6 I don't know what to say, and I am sure he's not going to want us to be the first one :)
Best of luck, jnap
See Marpa's irc channel, at http://irclog.perlgeek.de/marpa/2015-12-30#i_11806102 for some discussion re Perl 6 and parsing.
There's a risk is promoting Perl 6's parsing power for grammars if it can't deliver, and Marpa::R2 is the way to do parsing.
Marpa's home page is at http://savage.net.au/Marpa.html.
Admittedly, you need to define a BNF for Marpa, but that should not put anyone off.
Now, if only Perl 6 had a BNF for itself ......
http://irclog.perlgeek.de/marpa/2015-12-30#i_11804126
[Idiosyncrat] I note here the line about Perl 6 grammars, "which Perl 6 uses to parse itself"
[Idiosyncrat]That is not really true -- to the extent it suggests a feature that a Perl 6 adopter could use, it is certainly false.
I assume you are talking about the STD grammar (https://github.com/perl6/std/blob/master/STD.pm6) which can parse Perl 6 but isn't used by Rakudo. As to what Rakudo uses you can see that here: https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp
Feel a bit like the discussion comes from a place of relative ignorance of how grammars are used in Perl 6. I'd be really interested to hear discussions on performance. Especially if the ideas in Marpa can translate to the Perl 6 implementation. But it would be nice if that discussion was limited to facts. Especially coming from IRC comments where on the next page the author talks about trying to kill perceived competition YACC http://irclog.perlgeek.de/marpa/2015-12-31#i_11808105. Not exactly the most balanced or unbiased opinion out there. I'm a little surprised Marpa people wouldnt be excited to see more grammar stuff getting user facing for programmers. There's no reason Rakudo couldn't use Marpa if it were possible and capable of doing all the same tasks? Is that not worth even considering if the technology is apparently superior? Could definitely bind the Marpa C library in Perl 6 easy enough and hijack the core syntax from a module if you so wished. Then Marpa would retain its autonomy as a project and be an alternative to the core grammar engine.
With respect to use of BNF there is already plenty of work in that direction just not in the core language: https://github.com/tadzik/Grammar-BNF/ Some other relevant projects you might like to check out:
https://github.com/drforr/perl6-ANTLR4
https://github.com/andydude/p6-c-parser
Reads like wishful thinking and rationalisation. Betting your business on Node is more risky than you realise. In case you subscribe to the theory of hipster programmer migration passed around on conference hallway tracks, then you see that Node currently is the target of the "locusts" and they will in rather short time fall upon to the next shiny thing, perhaps Erlang, leaving behind burnt earth and empty husks. Visit your local Ruby user group some time and ask for stories about maintaining their Rails apps.
That makes me wonder if you have ever used them in anger. Earning my living involved Node for the last 1½ years. The libraries are indeed numerous, but of sub-par quality. All the work put into the libraries does not amount to something that meets expectations as the average JS programmer produces worse results than the average programmer from any other dynamic language (e.g. Ruby or Perl), mostly because of the huge amount of neophytes who are completely unaware of prior art and never would think of looking beyond their proverbial horizon. NPM and its ecosystem actually is a heap of junk:
I had a hard time getting things done in Node, it was comparatively easy in Perl. Some tasks were virtually impossible without the Node to Perl bridge; thank you hideakio and tokuhirom for creating that.
Even if well understood, it does not make them easy to work with at all. Libraries promise (hah!) to help paper over the deficiencies of the Node standard library. For non-toy cases, you have to always write extra boilerplate like in https://github.com/petkaantonov/bluebird/issues/196 , that's just awful. The real solution, async-await, is planned for Ecmascript 7. It's unknown when the accompanying implementation will land in Node, probably takes a couple more years. The equivalent in Python 3.5, C#, Perl (IO::Async/Future) and Perl 6 (start-await) is available right now.
@fmtyew.tk, I mostly don't disagree with what you said except for one thing. You're comparing Perl 5 to JavaScript. I have no intention of leaving Perl 5. But the point of this discussion is that Javacript seems to have more to offer than Perl 6, especially from a business perspective. I hope that Perl 6 gets there, but without discussion it likely won't.
But there are many more JS programmers around. I expect the ratio in Perl was similar a decade ago.
I don't disagree with your list of points about NPM and related ecosystem, but many of those apply just as much to Perl modules. I would suggest that comparing Catalyst to Express is bizarre, though - the latter is closer to something like Web::Simple.
We have reviews, yes - not many of them, and lots of politics in the ones that exist. metacpan votes are a curious beast, CGI.pm gets as many votes as Future.pm so I wouldn't consider basing any decisions on them.
Too many frameworks for the same thing - same in perl. Some of the better known ones might include Catalyst/Mojolicious/Dancer/Dancer2, Moose/Moo/Mo/Mouse, IO::Async/POE/AnyEvent/Reflex/Mojolicious but the same applies to many other areas, we have over 30 ORMs and most of them are rehashes of the same concepts, for example. We've had Module::Build, EUMM, Module::Install along with a laundry list of other things building on those. NIH is quite common on CPAN, I'm guilty of it myself.
Downstream packaging is not much better in perl - CPANPLUS::Dist::Deb has various issues and is mostly unmaintained, dh-make-perl likewise. No idea about other systems but I've had enough trouble just building .debs that I try not to waste time on it any more. Adding non-ASCII modules to your Perl distribution is an exercise in frustration - see the Acme::LookOfDisapproval commit history for examples. You can't even load them via -M without patching perl.
The extra boilerplate you mention in https://github.com/petkaantonov/bluebird/issues/196 is because "http.request doesn't follow the nodeback convention". Your claim that boilerplate like this is "always needed" is not my experience.
Note that node.js has a convention here: perl has none. We don't even have a standard Promises or callback or event implementation.
I'd love it if Future.pm was something other module authors would standardise on (I use it heavily myself) but we even have incompatible alternatives there (Stevan Little's Promises.pm, among others - and none of them even mention each other).
IO::Async / Future is in no way an equivalent to await/async. They provide some of the features of Node.js (with Promises/A features that are closer to Q.js/bluebird). Nearest we have at the moment is Coro - although there's a rumour that LeoNerd is working on an await implementation.
Note that even Future.pm needs a custom patch to be useful in larger applications - without this, any code that uses cancellation is liable to end up with futures that never complete (and you use cancel if you have any ->needs_all / ->wait_any calls in your code).
I love writing async code in perl5. Sure, the language doesn't offer any async-specific features, but is flexible enough to build lots of the async pieces without too much trouble. I wouldn't be too complacent about it, though: had to spend a lot of time writing CPAN modules to get to the point where async apps were feasible, and there was a fair amount of wheel reinvention in the process. Half the things I rely on for async apps aren't even on CPAN yet - we're slowly getting there, but far as I can see there just aren't that many people writing async perl5 code.
Node.js has the big advantage that people are mostly using async by default: the concept is deeply integrated, and I found that makes life easier even if quality does vary.
Dear JT,
I think you missed the point. Perl 6 is here so that there will be Perl jobs even in 30-40 Years.