With C++ I do find human medium-term cache capacity to be an issue. By the time I use C++ again, I forget some of the many little things I need just to compile a glorified "fizz-buzz". Things like, is this a pointer to a const or a const pointer? What's the syntax for a move/copy constructor? Keeping headers and cpp files in sync. What's the flag to enable modern C++ extensions? How do I write this lambda? Or make a pointer to a function? And so on...

Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.

- Things like Cython... let's just say experience is mixed. IME it is very hard to reason with its performance, and quickly it gets about-as-complex as writing your tight loop in a "natively fast" language.

- C++ is the standard Python companion, and frankly it can integrate amazingly well. You can define types in C++, native C++ functions, and define conversions between C++/Python. Then you can seamlessly make a C++ object in Python, pass it to the function and get the type back. It's not just about the speed, but also about the ability to really merge two languages together. BUT getting to that point is a massive pain of template errors.

- You could do it all in C, manually incrementing and decrementing refcounters. I'll leave it there.

- Other languages like Nim, Fortran and who knows what else seem to offer a limited ability to merge the codebases. You can use them, it seems, as a crutch to patch up some Python slowness here and there, but not as a comprehensive "here's two codebases that live side by side".

- Rust..? Might it be a replacement for C++ here? And is its complexity manageable.

Given that, I'm curious what bits of C++/python interop are easier.

I'm mostly asking because my experience of nim-python interop consisted of: Compile nim module with nimpy imported. Put compiled nim module somewhere where your python can find it. write `import <Name_of_module>` in the python file Done, you now have access to the exported functions and symbols defined in the nim module.

Is it that C++ wouldn't need any additional imports to make it work that makes it more seamless?

In C++, you'd write your C++ code as if you don't care about Python. Then, you add the "glue" code, which tells C++ how to convert objects to and from Python (there's more options than that but let's leave it here). That, plus a lot of boilerplate. Then, in effect, you can pass objects back and forth between Python and C++, create objects in C++, return them to Python, pass them back to more C++ functions, and so on.

I haven't used Nim+Python; but looking at Nimpy documentation, it looks like, for example, to export a class from Nim to Python, it needs to inherit from a special underlying class. You can't just take a class and make it available in Python. And even then, can you pass that back to Nim to call a function with?

Maybe yes, and if so, that bumps Nim higher up my priority list.

In terms of seamlessness, I can not confirm that it is exactly like having a python class, merely "fairly close". If you define a type, you can pass it to python, python can instantiate (with the typical way of Type() ) or even receive instances (if you define e.g. a constructor proc yourself). It can pass the instances back to nim to work with no problem (see e.g. quick example I whipped up: https://pastebin.com/v5wAqGxZ).

However, I have found that there are differences of a nim-type to a pythonclass:

1) In python you do not have direct access to the fields of an instance of a nim-type. You can access them via getters and setters, but you'll get runtime errors if you try to access them directly. To make that behave seamlessly you'd need to define a python wrapper class and hide stuff with @property decorators. Without such a wrapper class you could also not add a field to an instance of a nim-type like you could a normal python object.

2) An imported nim-type can not be inherited from in python (not sure if that works in C++, but at least it's a nim-python-interop limitation).

If you wanted to make a library in nim available in python that wasn't originally intended for the export, you'd likely also need to write a glue-layer in nim. The efffort there would consist mostly in copy pasting the proc signatures you want to make available and annotating them with the export-pragma, copy pasting the nim-type to make it inherit from the type needed for exporting and converting from the exported nim-type to the imported nim-type or vice-versa when jumping from python to nim or vice versa. Further, to hide the short-comings (that you can't inherit and that you don't have access to fields or can add fields) you'd need to wrap the nim-type in a python-class as described in 1).

My conclusion from what I heard from you so far and what I know of nimpy would be, that nimpy is 90% of the way there, workable but not as seamless, given that exported nim types and their instances aren't functioning exactly like python classes and their instances. Further the fact you'd need to wrap them in a Python class to hide that means, in comparison, extra work to C++ (though that may balance out with if the glue layer in C++ is more involved than the one in nim, I don't know).