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 NativeCall.
https://docs.raku.org/language/nativecall 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: https://raku.land/cpan:MARTIMM/Gnome::Gtk3 https://raku.land/cpan:TIMOTIMO/SDL2::Raw https://raku.land/github:JJ/SDL2 https://raku.land/github:hartenfels/Text::Markdown::Discount (There's a bunch more too). Good luck :) On Wed, 29 Sept 2021 at 08:49, YueCompl via perl6-users < perl6-us...@perl.org> wrote: > Also asked at > https://www.reddit.com/r/rakulang/comments/pxqaxi/whats_native_ie_highmachineperformance_hybrid > > > 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]( > https://www.youtube.com/watch?v=rxaB6m_sQKk). > > 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](https://stackoverflow.com/a/50125447/6394508 > ). > > 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 http://www.khanate.co.uk/
