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