| > 2. It now means you need multiple language specialists to maintain it and associated communications and context switching. Sometimes you have that and you need to accept it. In this case the function was really trivial. What if it was a mega secret algorithm that needs Rust speed which you want to really write in Rust because XYZ? Or C++ I don't care. But not Go, which you want to use exclusively for microservices, for example. > 3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface. This is inevitable when you want to go that low level. Some companies use C++ for everything, some mix low/high level: how do you do in that case? This article is about Go, but I could imagine something similar for Python: use something superfast under the hood, python for the high level part. It's really a common solution, which requires a bit of bindings left and right but it's worth it. > 4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required. This is how software is done today. Maybe 30 years ago you would write everything in C and be happy with it. Today companies use at least 3 programming languages - at least that's my experience. |
That's not a bad idea really, the wasm/wasi option could be a nice intermediate step between "we can't optimize the python any further" and "write a native extension" (or god forbid use cffi or the cursed horror that is ctypes).