Okay, I’m going to entirely skip over “Perl 6,” whatever it turns out to be, and go straight on to what I could actually use right now. Any takers?

I want “Perl 7” to consist of a use moose; implementation that is 100% compatible with the current Perl 5.x, passing each and every existing test without exception or variance, but 25% or more faster and using 25% less system resources.

This is not going to win you brownie-points at the next Language Designer’s Conference. You are not going to be able to lay claim to revolutionizing the world of computer programming with your splendiferous ideals. In fact, your peers at such a conference are likely to give you pitying looks, as though you had been tasked with building a beautiful new archway over the entrance to a supermarket.

However, I could use it right now ... and I suspect that I am not alone in this.

It would also be excellent if your implementation ... which of course would be optional in that I could flip it off-and-on and know that my software will still work as before ... also introduced a greater sense of compile-time error checking into the Perl language, at least insofar as the Moose constructs are concerned. Perl really doesn’t have a “compile-time” to speak of, yet Moose, in a very sideways sort of way, does introduce semantics that could be compile-time checked. That would be very useful.

The best(?) thing is: you, the designer, don’t have to design anything new. (In fact, you are forbidden to design anything new.) Moose, by now, is already well-understood and already in production around the world. Your task is to create a more efficient implementation of it. (Oh, how utterly boring.)

I think the Moose (and Moo and Mouse) devs are doing a brilliant job of wringing out performance and if I was one of those devs, I would find a general requirement like "25% more efficient" kinda insulting. If you want to dig, find bottlenecks and post them so that they can make their projects better, I'm sure they'd appreciate the hell out of that.

Ovid had a nice blog piece along the same lines -- renumbering 5.20.0 to 7.0.0 -- I think the general consensus was no. In that blog piece, there is talk about project Moe which may be what your after.

For what it's worth, Mouse is much more than 25% faster than Moose (at least it is on machines where it's been compiled with XS; Mouse::PurePerl is very slightly slower than Moose). While it appears to offer good compatibility with Moose; this is on the surface only. Things start to break if you try to consume a Mouse role in Moose, or extend a Moose class with Mouse.

Moo has far less of a start-up penalty than Moose, but when it comes to running speed, isn't quite as fast. On the surface it appears less Moose-compatible (but see MooX::late) but it's designed to be able to interact nicely with Moose. You can extend Moo classes with Moose, consume Moose roles in Moo, etc.

The only places I can see big scope for Moose optimization are:

Allow inlining for things like defaults, triggers and coercions. This would slow down the speed at which your class loads, but improve the speed at which it runs.

Rewrite large parts of the internals in XS. This would likely improve the speed of Moose itself, but not alter the speed of your class. (It would also make maintenance of Moose more annoying, and thus turn away developers.)

I've published a couple of modules on CPAN that might be of use if you're trying to eke a little more speed out of a lumbering Moose...

MooseX::XSAccessor - which replaces some of your accessor methods with faster XS-based ones, but only when it detects that it can do so without breaking any functionality. (Again, I have benchmarked it.)

I must have missed that blog post. I'd be one more vote in favour of the proposal. A rewrite that turned into a totally different thing and is ten years overdue, but that blocks the next version number has caused enough damage already. Let's skip the number and force rename of the rewrite!

I love what "themoniker" wrote in the comments to that blog post. It's spot on.

Update: In a fairly strongly worded response to my recent comment to that post Aristotle suggested that I look at the git repositories of the various Perl6 related projects. OK, so let's have a look how live is that.

Rakudo contributors - jnthn 4,178 commits; moritz 2,590 commits; pmichaud 2,363 commits; then a steep fall to colomon at 607 commits (very active in 2010, almost disappeared after that); going down to masak at 295 commits and particle at 226 commits (masak commits now and then for years, particle disappeared in early 2009); then we have coke (205) and tadzik (204) - both active mainly in 2011 but still committing now and then. The rest is under 100 and most of the charts show a spike somewhere and nothing before or after. By the time we get to the 30th name we are down to 12 commits.

NQP contributors - jnthn 2,400 commits; pmichaud 850 commits; moritz 298 commits (haven't I seen those names somewhere?); then down to arnsholt at 97 commits, sorear 78 commits, bacek 59 commits; masak 46 commits. After that we see the familiar pattern of a spike and disappearance with an occasional exception. By the time we get to the 30th person we are down to 4 commits.

Update: Realized I was giving JimmyZ and Arnsholt, much as I love 'em, a little too much credit. ;)

You seemed to have assumed that you've picked three key repos and that if some folk slowed commits to the main branches of these 3, then P6 dev was slowing and the missing contributors had slowed their contribution to P6. These assumptions are incorrect, as are others such as all commits and contributors being equal. Line count isn't going to be a better metric either. I recommend you visit the IRC channel #perl6 on freenode and ask questions; you'll get a much better picture of what's really going on.

At least 13 of the 14 folk you named remain active P6 contributors. (I'm excepting particle; he joined #moarvm a few weeks ago, but afaik he hasn't committed anything in a long while.) 11 of the 14 folk you named are highly active, currently contributing somehow near every day, 5 or more days a week, most for years. (The additional three exceptions are pmichaud, the P6 and Rakudo manager, who is occasionally committing and otherwise contributing but can't be said to be doing so most days; bacek, who contributes in fits and starts but hasn't done so for a few months afaik).

Of the top 50 contributors to the rakudo\rakudo repo, about 20 speak up on #perl6 pretty much every day and have landed commits to some P6 project repo (not just a personal P6 project) in 2013.

Of the bottom 50 rakudo\rakudo contributors, I recognize 15 of them as #perl 6 regulars in 2013, some making commits. (The numbers may well be higher than I recognize.)

The NQP repo includes several Parrot contributors (partly because NQP had a strong overlap with Parrot a few years ago) and Parrot dev has slowed tremendously. Even so, 26 of the 44 committers to the NQP repo since 2009 have NQP repo commits in 2013.

Ignoring whose contributing to what and how, Rakudo and NQP are both advancing rapidly, imo faster than in any previous period.

The main action in Rakudo/NQP land right now is getting the port to the JVM to the next level (ready for experiments with parallel processing, running on Android, etc.). I expect that to remain the focus in July, possibly August too. If you're trying to see where this Rakudo action is, follow branches in the Rakudo and NQP repos, or in forks folk have created, related to Rakudo/JVM. Note that since YAPC::NA, sorear, the creator of Niecza, has joined forces with jnthn on this port so now both of these two extraordinary hackers are working on Rakudo.

Others continue to work on the compiler ignoring the backend stuff. Watch the likes of timotimo, FROGGS, and newcomer ssutch.

Talking of timotimo and ssutch, note that these are both long time pythonistas that seems to have fallen in love with P6. It's interesting that the P6 project seems to be attracting contributors from outside the Perl world as much as from within. It's also interesting that ssutch was able to jump in to the compiler's guts and produce a working non-trivial patch in his first week of exposure to Perl 6.

Finally, MoarVM. The MoarVM repo was secret until 4 weeks ago. It has tripled the number of committers it has in 4 weeks, with several new contributors being well known uber hackers. (Chip Salzenberg has joined the channel!)

Here are the contributor graphs over time for the three repos you looked at: rakudo/rakudo, perl6/NQP, MoarVM/MoarVM. I agree they don't show a significant ramp up, but they don't show a significant ramp down either. The team is getting these pieces done, with or without help from others in the Perl community.

The above is focused on the three repos you picked. But there's lots more to P6 than those three repos. The module installer and ecosystem, key modules, testing components (including testsuite and japhb's workbench), rakudo debugger, Zavolaj FFI, documentation and so on are all important pieces. Check out the commits reported on #perl6; these are a good first approximation of the key P6 repos.

In summary, there have long been about 20-30 regulars, 50-70 occasionally returning irregulars, and a trickle of new folk, that are steadily building out Larry's vision.

Right now the vibe on #perl6 is very positive. The outlook for the rest of this year and 2014 is a joy to contemplate.

One last thing. Consider P5. I've heard that there are only 3 people in the world who deeply understand the guts of #p5p Perl 5: Nicholas Clark, Dave Mitchell, and Father Chrysostomos, and that they consider it a tough situation. Indeed, one of these three, Nicholas Clark, is now a regular on #perl6, and my understanding is that he sees P6 as being poised to deliver a technically excellent strategic way forward for P5 that sidesteps the deep problems of #p5p P5 without abandoning P5 (Pumpkin or otherwise). Talk of 25% improvement in the speed of the current p5 or Moose is easy; but just you wait until you dig in to the details...

Really, the best way to understand P6 is to visit the IRC channel #perl6 on freenode and hangout. Try it. I bet you'll like the folk even if you don't like the language!

So, are you able to offer any time and/or resources to improve the performance of Moose?

I'm also wondering if a request for 'faster' and 'less system resources' is a red herring. There are system architectures you can use to improve performance -- you can cache a bunch of things, you can move from spinning rust to solid state drives, you can spread the load across multiple servers, you can set up geographically dispersed data centers .. the list goes on.

No insult is meant, of course, and “25%” is simply meant as a carelessly-discarded gauntlet. I would particularly like to see the appearance of true “compile-time checking” in Perl, within the scope of this limited and optional (but, by now, well-defined) context. I’d like to see what would basically be the equivalent of “recoding a whole bunch of stuff in XS,” but instead doing it within the main-line compiler/interpreter itself: expanding the perlguts of the thing. Yes, expanding the scope of what is “the Perl language,” but doing it in the most pragmatic way possible. There would be none of the “gee, I think this-or-that would be Cool” thinking that torpedoed the last attempt. This is the target, and we have thousands of proven tests that show what that target is, and we are going to expand the core-language implementation itself: both to optimize the runtime characteristics of this, and to facilitate compile-time checking of types, calls and so-forth to detect errors much sooner than we can now do. We are not going to change this at all. We are going to provide an entirely-optional fast track, and we are going to break absolutely nothing in the process of doing it.

Instead of debating endlessly about some –er” re-making of Perl into what it is not, why don’t we focus our efforts on streamlining a part of the system that is right now in regular daily service, and in improving our system’s ability to detect source-code errors sooner than at-runtime. This goal is fully-defined (and fully testable) right now, it has reasonable scope, and it has ROI.

I mean this as no “red herring,” Talex. I merely offer the observation that “the worthy successor to (so to speak) Perl-5” just might have been staring us all in the face for several years now. And it isn’t called .. god only knows what they call it these days .. it’s called Moose. If we turn our attention to implementing Moose within the actual perlguts, we just might obtain a timely return-on-investment.

(I hope that I am not speaking to an empty chapel here ...)

I’m not sure that performance is necessarily the big-win here: the Perl core is already so efficient that it can actually withstand Moose being grafted on top of it. To me, compile-time is the biggest potential win/driver to the idea. Unlike “regular Perl,” Moose does have the potential to introduce strong-typing. isa => 'int' might constitute “laborious syntax,” but it nevertheless could serve to associate a strong-type with an attribute ... a strong-type that could be made to have “teeth,” including before the program starts to run.

Furthermore, we will have moved out of the “pie-in-the-sky hypothetical Land Of –Er,” and back into a frame of reference that has already been implemented and put into production many thousands of it-pays-the-bills right-now times.