Raku is not fast for mostly different reasons. Right now one of the slow parts is the regex/grammar feature. So code that uses that feature is a bit slower tha

Raku is not fast for mostly different reasons. Right now one of the slow parts is the regex/grammar feature. So code that uses that feature is a bit slower than it needs to be. The compiler uses the regex/grammar feature, so your code compiles slower than necessary. Since this feature has mostly been left alone for years, it makes sense that it is a bit slow. Hopefully someone will volunteer to improve this soonish. Much of the slowness is actually caused by the dynamic design of the language. (Which are perhaps its most awesome set of features.) As for the slowness caused from dynamic typing, it mostly goes away after the runtime type specializer built into MoarVM gets a chance to optimize it. This is the step before the JIT, and it is actually more important than the JIT for performance. (It also optimizes the dynamic features noted above.) The type specializer could in the future make it so that bog-standard Raku code is eventually as fast, or faster than bog-standard C. (The runtime type specializer has more information available to work with than a C compiler could ever hope for.) Of course hand optimized C would probably still outperform Raku at that point, but you can also hand optimize your Raku code. There has already been one report of Raku (Perl6 at the time) being faster than the C/C++ equivalent for one workload. There have also been several important optimizations since then. (I'm fairly sure the slowness of the C/C++ version had to do with copying strings and looking for null terminators of strings, neither of which Rakudo on MoarVM does.) --- For more information watch the videos of, or read the slides from: “Escape analysis and related optimizations for Perl 6” -- Jonathan Worthington (jnthn) and “Perl 6 performance update” -- Jonathan Worthington (jnthn) (If you are only going to watch one, make it the latter one.)