For the record, this is because our use case is some different from simply wrapping a mature C/C++ lib/component with less frequent API changes. We keep actively developing new functionalities, as high-performance core code, wrapped to have varying scripting interfaces. Design model exploration is literally our core business.
> On 2021-09-29, at 18:10, YueCompl via perl6-users <perl6-us...@perl.org> > wrote: > > 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 >> <mailto: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 >
