From the article:<p><i>&gt; when you are crossing the language barrier and deciding the boundary between what should go in the high-level language vs what should go in C or C++.</i><p>While performance considerations are indeed a good indicator about where to make the high-level &#x2F; low-level split, there is more to that.<p>I believe that having a small, stable interface is even more important. Even if that incurs a small performance penalty, a small interface will free you from having to add lots and lots or more tiny foreign function call as your application grows. It also frees you from writing converters and wrappers all over again, which can be partly automated, but not fully.<p>Reducing the interface can save a lot of development effort with usually just a tiny performance penalty.<p>Moreover, in one case I was even able to recognize that all I need is some C++ code to perform batch processing. So I was able to get rid of the wrapping as a whole, and compiled a separate C++ command-line instead. The FFI code was replaced with a simple &quot;exec&quot; with IO redirection. The wrappers were just creating a JSON structure in the high-level language, and loading that on C++ side. This resulted in code which is a lot simpler than initially expected, and even in a separate command-line tool that is useful on its own, and can trivially integrated into any other high-level language.