Raku seems to be stuck in a "we'll optimise that later" dead-end, especially with string processing. Parse a large log file with a regex and compare Raku with Perl5. Raku has a long way to go.
> Raku seems to be stuck in a "we'll optimize that later" dead-end … Raku has a long way to go.
I agree that Raku still has a long way to go in terms of performance – it's not nearly as fast as it has the potential to be.
That said, I strongly disagree that Raku's performance is stuck. I've only been using Raku for about a year, but even in that time I've seen a noticeable improvement. Over a longer period, Raku has gotten dramatically faster – around a 10× improvement from the 1.0 Christmas release, depending on how you measure. For details, check out this 2019 talk where one of the lead Raku developers discusses performance gains/plans. ([0] video; [1] slides)
There's definitely still work to do (especially with regexes and grammars, as you mention). But the language has made tremendous progress, and is now in the same basic range as Python/Ruby/Perl.
Agreed that both Raku (the language, community, and ecosystem) and Rakudo (the compiler) have a long way to go.
But whose who know them well know that there's still lots of low hanging fruit and it's "just" a matter of continuous improvement, year by year.
> stuck in a "we'll optimise that later" dead-end
That's a bit like saying Java (or rather the JVM) seemed to be stuck in being dog slow based on its dog slow performance in the first few years of its official existence. It paints a false picture.
In reality JVMs got faster each year, sometimes by big jumps, and 10 years after Java's first official release it was still slow, but no longer dog slow. (And nowadays Java is no longer considered slow.)
What matters is whether there is sustained love and continuous significant improvement of a PL, and an implementation. Raku has demonstrated that it has that for 20 years, and Rakudo for 10.
There is good reason to look forward to that continuing for both Raku and Rakudo until well beyond the point at which its raw string processing performance has become respectable.
And this will be in addition to what's remarkable about Raku's string handling, namely its world leading Unicode support and O(1) string indexing. Presuming that will finally pay off, and I see no reason to think it won't, it will seriously pay off.
I think Raku's Inline approach will one day eliminate that suffering and replace it with the even larger advantage that Raku's ecosystem will trend toward being the sum of other PL's existing ecosystems.
Consider the Perl modules on CPAN. Raku's ability to just use many of these existing Perl modules, including ones that use XS, completely unmodified, running via standard perl binaries, and thus running exactly the same as they would be if run standalone instead of within the Inline harness; and using standard Raku syntax, as if Perl modules were native Raku modules; all of that, done well, is an extraordinary breakthrough.
Stefan Seifert did remarkable and respected work for a decade on some of the most important Inlines that Perl folk use; imo his 5 years of work on the Raku evolution of that notion are far more remarkable in terms of the long term implications I see as I watch the maturing of the Perl Inline and look forward to the anticipated redo of the Inlines for other langs to catch up with the Perl Inline.
Actually, it is even simpler than that. If you have the Inline::Perl5 module installed, then the only thing you need to do to load a Perl module, is to use the :from<Perl5> adverb in the -use- statement, e.g.:
