develooper Front page | perl.perl6.users | Postings from September 2021

Re: What're native (i.e. high-machine-performance) hybriddevelopment options with Raku?

Thread Previous | Thread Next
Simon Proctor
September 29, 2021 09:13
Re: What're native (i.e. high-machine-performance) hybriddevelopment options with Raku?
Message ID:
I'm sure there are people who will be able to give some more information
than me but I will say you can do worse than reading the documentation on

I've played about with it a bit and it really is quite simple to get
started with. Generally you can directly map to a C/C++ call and then wrap
that in a nicer interface if you want to.

Some example modules already using it:

(There's a bunch more too).

Good luck :)

On Wed, 29 Sept 2021 at 08:49, YueCompl via perl6-users <> wrote:

> Also asked at
> Greetings!
> u/raiph is really a great evangelist, months ago, he swept away my (wrong)
> assumption that Raku must be mostly old school PERL, and keep impressing me
> with fantasies already done by Raku. Recently being [compiler in minutes](
> I'm considering seriously the realworld adoption of Raku in my work, so
> I'd like to ask this.
> My current (private) framework facilitates the writing of high performance
> tensor components in C++, those get assembled to computation networks with
> Python scripting at runtime, then run mostly in C++ code but occasionally
> call back to script code. There had been even older workflows with Boost,
> but I started with Pybind11 a few years ago, with the approach pretty much
> described in [this SO answer](
> ).
> As our business develops, more and more expressiveness is demanded, Python
> magic methods way of language tweaking becomes a limiting factor gradually.
> We are currently using a custom scripting language I implemented fresh new,
> atop Haskell/GHC, with script-assemblable high-machine-performance
> components writable in the `IO` and `STM` monad. I share many of Raku's
> design ideas in implementing that PL, but failed to discover that before
> u/raiph caught my attention to Raku.
> Apparently Raku is more mature and feature rich than my current piece,
> especially in syntax customization, that we demand heavily.
> But I'm not clear by far, what's the approach for Raku code with native
> parts get developed with good ergonomics?
> The native parts is not expected to be C/C++, but some PL with moderate
> raw machine performance, and ergonomics is very important, so manual memory
> management is a deal breaker for us. For example, Go's machine performance
> is acceptable by us, but Rust is not due to memory management burden (even
> though much more principled than C).
> The scripting part cries for flexibility and clean-ness in
> syntax/semantics, toward purity of business concerns, ideally no computer
> implementation concerns should surface to the scripting grammar, machine
> performance in scripting is not sensitive at all, since it is just to build
> one variant of the business program, the "real" run of the program should
> mostly consist of compiled native code. Though calling script parts back,
> meanwhile the high-performance run, is also desirable in a small number of
> scenarios.
> That said but Julia's approach - LLVM based JIT from scripting, is not
> affordable by us, we have no expertise in machine code generation, even the
> simpler IR manipulation.
> Also debuggability in the native code part is crucial, C++ served us well
> in this regard, VSCode etc. can attach to a Python process and set
> breakpoints on the C++ code, then step through the suspicious code path.
> Haskell is far from on par w.r.t. stepping debuggers, but bugs are
> interestingly less with it, for unutterable reasons.
> Best regards,
> Compl

Simon Proctor
Cognoscite aliquid novum cotidie

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About