Thanks! But as I said, C/C++ is a deal breaker for us. I think Raku is garbage collected itself, it'll be hell if the native code we write will either have to manage memory manually, or interface with Raku's GC routinely.
Back there, Pybind11 would manage C++ objects with smart pointers transparently as Python objects and vice versa, usual cases work seamlessly well. And further we'd like to stop worrying about smart pointer or any pointer semantics altogether, in the next generation of the framework/platform, and Haskell is serving this purpose really well so far. > On 2021-09-29, at 17:49, Fernando Santagata <nando.santag...@gmail.com> wrote: > > I can add that the NativeCall interface works exceptionally well, even > allowing one to pass a Raku sub, closure, or anonymous block as a callback > into a C function. > > For example: > > https://raku.land/cpan:FRITH/Spreadsheet::Libxlsxio > <https://raku.land/cpan:FRITH/Spreadsheet::Libxlsxio> > On Wed, Sep 29, 2021 at 11:14 AM Simon Proctor <simon.proc...@gmail.com > <mailto:simon.proc...@gmail.com>> wrote: > 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 > <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:MARTIMM/Gnome::Gtk3> > https://raku.land/cpan:TIMOTIMO/SDL2::Raw > <https://raku.land/cpan:TIMOTIMO/SDL2::Raw> > https://raku.land/github:JJ/SDL2 <https://raku.land/github:JJ/SDL2> > https://raku.land/github:hartenfels/Text::Markdown::Discount > <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 > <mailto:perl6-us...@perl.org>> wrote: > Also asked at > https://www.reddit.com/r/rakulang/comments/pxqaxi/whats_native_ie_highmachineperformance_hybrid > > <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 > <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 > <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/ <http://www.khanate.co.uk/> > > -- > Fernando Santagata
