3 ms·

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

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

KingMob 3y ago
> makes light of I assume you mean "makes light work of". Making light of something means to disparage it, usually as frivolous/unserious/etc.
- librasteve 3y ago
  guess your a Rust coder by nature
pjmlp 3y ago
> 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.
- librasteve 3y ago
  fair point, perl5 is pretty fast too 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
  - pjmlp 3y ago
    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. Then there are all the other JVMs.

KingMob 3y ago

> makes light of I assume you mean "makes light work of". Making light of something means to disparage it, usually as frivolous/unserious/etc.

librasteve 3y ago
guess your a Rust coder by nature

pjmlp 3y ago

> 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.

librasteve 3y ago
fair point, perl5 is pretty fast too 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
- pjmlp 3y ago
  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. Then there are all the other JVMs.