That was 5 months ago. A lot happens in this space in two weeks let alone half a year. Rakudo is released monthly still, with quarterly(ish) distribution releas

That was 5 months ago. A lot happens in this space in two weeks let alone half a year. Rakudo is released monthly still, with quarterly(ish) distribution releases. An example bit of insight: https://github.com/rakudo/rakudo/search?o=desc&q=fast&s=committer-date&type=Commits https://github.com/rakudo/rakudo/search?o=desc&q=fast&s=comm... That's just the compiler rather than VM or NQP level, where you will see even more performance related work. One of the bigger breaking changes in 6.D at the language spec level is for performance of scheduling multi threaded work. https://github.com/rakudo/rakudo/pull/1004 https://github.com/rakudo/rakudo/pull/1004 The main canary test for performance used by the community is the Text::CSV module. The vanilla Raku implementation is about 2x slower than the C wrapping Perl equivalent. The nice property of the Raku library is you can run it in parallel quite trivially and then its suddenly faster than the Perl version. In general the simple introduction of hyper/race keywords into user code is a big win for performance, but perhaps not cost. There are a tonne of features of the language specific for performance most people walking through the door aren't so aware of. Native type decorating your code and variables for example, usually invokes significant improvements to numeric work. The JIT does some of that automagically but simple issues like your code implicitly switching between rational and floating point types will break optimisation. If you don't say what you really want to do Raku always assumes you want to do the safest and usually slowest thing like use bignum or rational type things, that are harder to speed up down at the CPU.