> And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem
Absolutely no way is this a fine way to solve the problem. That is crazy talk.
1. It introduces additional toolchains into the solution when it is unnecessary.
2. It now means you need multiple language specialists to maintain it and associated communications and context switching.
3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.
4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.
This makes no problems easier at all! It's even a bad last resort if that's all you have left to try.
Sound software architecture is very very well defined and this is definitely not it. I have seen entire companies burn by taking this approach to problem solving.
I'm really getting tired of solutions before problems and this is a fundamental example of it. Give us a real use case not manufacture a problem for it.
> 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.
> 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.
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).
> Absolutely no way is this a fine way to solve the problem. That is crazy talk.
I disagree. I see this in a similar way I see Electron and actually you can make the same arguments against using Electron.
But guess what, Electron wins on practicality. It makes creating GUI apps much easier. That wins over any problems associated with the extra baggage of shipping a whole browser. It doesn't win it for everyone, but it does for the majority of people who just want to get shit done.
Absolutely no way is this a fine way to solve the problem. That is crazy talk.
1. It introduces additional toolchains into the solution when it is unnecessary.
2. It now means you need multiple language specialists to maintain it and associated communications and context switching.
3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.
4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.
This makes no problems easier at all! It's even a bad last resort if that's all you have left to try.
Sound software architecture is very very well defined and this is definitely not it. I have seen entire companies burn by taking this approach to problem solving.
I'm really getting tired of solutions before problems and this is a fundamental example of it. Give us a real use case not manufacture a problem for it.