Yes, they may eventually solve the XS problem. They don't now, and to my knowledge neither has a credible solution to do so. Anyone who suggests otherwise—anyone who suggests that Moe or v5 is useful and usable in the same way that Perl 5 is now—is spreading misinformation.

To be fair to Moe, no one has ever suggested that it is a worthwhile replacement for Perl 5.

a worthwhile replacement for Perl 5.

I still don't get all this endeavour to re-write P5 in P6. P5 is perfectly embeddable.

Just embed perl5xx.dll/.so into the P6 compiler and provide:

1. P6 built-in(s) to access p5 subroutines:

   Say something like:

   use P5 qw[ LWP::Simple ];
   ...
   
   my $url :String = <...some P6 source>;
   my $content = p5call( "LWP::Simple::get( $url )" );
   [download]

   ).
2. P6 proxies for P5 objects:

   Say:

   use P5 qw[  DBI DBD::Pg ];
   
   ...
   my $dbi = P5Object( "DBI->connect( $dataSource, $userName, $userAuth, 
   +\%attrs" ); );
   my $sth = $dbi->prepare( 'SOME SQL HERE' );
   ...
   [download]

Full compatibility at a stroke, and full P5 performance (within the p5 code), and a small hit through the thunking layer.

How hard could it be to write the thunking layer? (It's gotta be easier than recreating P5 + XS + everything else.)

I effectively do exactly this in my 15-line Perl5 REPL.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

How hard could it be to write the thunking layer?

Keep in mind the current mindset is that everything has to be portable across all of the (hypothetical) backends that Rakudo (hypothetically) supports, so writing a thin embedding layer in C won't do. You have to write it in NQP and then hope that the backend allows you to invoke C functions in an efficient way. That's C for Parrot, JNI for the JVM, something like P/Invoke for the CLR, wishful thinking for v8, and magic unicorn fairy dust for MoarVM.

It's gotta be easier than recreating P5 + XS + everything else.

If P6 is optimized for -Ofun, then plumbing and maintenance and packaging and all of the other pieces of finish work that aren't glamorous must not be fun.

P5 is perfectly embeddable. ...

The architecture of what I called Mixing P6 and Perl 5 with XS in my recent Perl 6 <-> Perl 5 bridges comment is pretty much as you describe. (Though, aiui, it'll take more than 15 lines of code.)

the celebrity tell-all of the Perl-6 cult

To be fair to me, I did not (mean to) suggest that v5 is a replacement for Perl 5.
the celebrity tell-all of the Perl-6 cult