Metaprogramming will struggle to go mainstream. It's the way you shrink a 50,000 line program down to 1,500 lines that nobody can understand but the author. I absolutely love doing it and I think I could hand the code off to somebody and have them make small changes in the DSL code but if they have to change something in the implementation to extend the DSL all bets are off.

After all these years we still don't have macro assemblers as good as what the IBM 360 had even though we now have architectures that have enough registers that it would be reasonable to pass a register name as an argument to a macro like you could do in IBM Macro Assembler.

Like most scripting languages (e.g. Python), execution speed was not the top priority - in fact, like Python, most heavy lifting can be / is done by modules that are written in native C code, or Rust or similar via the C FFI / Inline::Perl interfaces.

To your point, I recently measured the compile time of this raku module...

# speed (2020)

# use Physics::Measure :ALL; ...13s first-, 2.8s pre- compiled

# speed (2024)

# use Physics::Measure :ALL; ...4.4s first-, 0.9s pre- compiled

... so about a 3x speed up in the last 4 years.

Also raku has no GIL and has good support for hyper / race so can get a lot out of your 32 cores (if you want speed).

Another raku module to mention (Dan::Polars) connects to the Rust Polars library via FFI (thus getting Rust level execution speed since Polars a lot faster than Python Pandas via the underling Apache Arrow data structures) ... this takes about 2s for the raku to compile and about 15s for the rust cargo stack to compile ...

When was the last time you checked performance? :-)