> Tikka throws her arms around her daughter and says, “Well, I sure am glad I was listening to all your chirping about Zig! It looks like we have a workable solution for speeding up our Raku code to handle the peak load!”
> Tamala squirms, trying helplessly to dodge her mother’s love attack.
nice summary - Raku’s strong NativeCall (FFI) support makes light of integrations like these - C, C++, Python, Perl5 are all good targets and handy for grabbing packages from PyPI and cpan when the raku ecosystem (2777 packages and growing) doesn’t yet have a native module
all dynamic languages compromise on execution speed and often a Python package combines a fast C execution engine - Raku modules can build in binaries in an analogous way
when it comes to dropping into a low level code for a speed boost, for a while I have thought that Raku + Rust is a good combination (akin to Python + C), for example to integrate to the blazing fast Rust Polars data science module
looks like Zig is an even better bet for a lightweight glue layer to harness a C library (or roll your own low level accelerator), especially since the safety aspects of Rust are reduced whenever FFI comes into play
> all dynamic languages compromise on execution speed
Not all, some of them bring a JIT compiler, or several, in the box, reducing the need to reach out to compiled languages as step zero on optimizations.
Some of them even support AOT compilation, alongside low level systems programming, like BASIC, Lisp, Scheme or Dylan.
the raku vm (moarvm) does have jit already but until the current AST work is done, it is limited in the depth of code inspection it can do to meaningfully accelerate
even with very mature jit (eg. java) it is not generally possible to outperform static compiler optimisations
On Java case, depends on which toolchain it is being tested, how many JIT levels it supports, if PGO is part of the picture, if it does JIT caching, if there is an AOT compilation available as well.
On Android/ART, multiple factors collaborate for the best AOT compilation with optimising compiler, when the device is idle, while a tiered JIT does its best, depending if PGO data was downloaded alongside the APK, or needed to be generated from scratch.
In this case you basically have a server a long running process that does the same code many many times.
If you're careful of memory allocations, the JVM may be able to beat this.
I just skim the article. Is the essential of this article just being able to call fast language x from slow language y, except for trendy languages Z and R?
there is some talk in the Raku community about porting some of the moarvm code to Zig … so this is one of the core devs getting their feet wet as part of the raku advent blog … based on this ‘spike’ they make a good case
> Tamala squirms, trying helplessly to dodge her mother’s love attack.
cargo uninstall mommy-rs