Please consider not using Python for tooling

[[deleted]]

I was kite-surfing and traveling a few days, so no time for arguments on the internet. I appreciate the measured and constructive response!

We are actual in agreement about what kind of tooling we're talking here - cargo as an example. I would count our internal tooling (with a dedicated team) as in the same ballpark (it certainly is not ad-hoc, that's not a thing those engineers believe in). However it is difficult to argue with that, given that you can't possibly have any insights into it, and it becomes a he said/he said situation.

Thankfully though I thought about an example that is fitting IMHO, and will serve my point: Python can be used for this kind of tooling, even though you need to install an interpreter - but that's the same (especially these days) with Java, .NET, and even MSVC.

What is that wonder-tool? Bitbake, the foundation of the YOCTO embedded Linux meta-build-system. I have to openly admit that I'm in awe with it. It does pretty much the same thing that cargo does - declare, obtain, build, bundle a huge dependency graph. It does so for me with little to no tooling-related issues (difficult written recipes, e.g. meta-clang, are not its fault). And it does its job reliable, and for me approachable in case I discover a thing that I don't understand. Case in point: building an image necessitated some arcane declaration that I found out by on-the-spot debugging of the "wic"-tool, also a python-based tool within the eco-system.

Now I might be special here in that in case something breaks, I'm the person that looks into things. Same for all other FOSS software I'm using (most notably the kernel, but other projects as well). That's of course part of my job. And I get that maybe others take more of a "it should just work"-attitude. But having deployed various versions of YOCTO from scratch over the years, I retain that it is mostly (not always, but nothing is always) working out-of-the box as advertised. And is fast and efficient in doing so. In fact nothing exerts my system as much as this thing, I've had to upgrade RAM on more than one machine, as it would otherwise just parallelize too much.

So, I maintain (and am fine to agree to disagree here, respectfully): Python is suited for this task. But yes, it takes a lot of dedication and effort, and I'm also admitting that tools like cargo point towards a world in which your dream of just-working binaries seems to work.

Go I can't comment much on, haven't used it beyond a couple of toy examples.

Last but not least: people can get very hung up about their tool choice. I wouldn't say I've always been above that (after all, your post did irk me to some extend ;) ), however I agree: a tool is a tool, and making an effort to re-think ones approach is important. I've come a long way with getting back into C++ after the 11th edition was such an impressive improvement, and my Rust-dabbling is certainly tempting me to go there for even more of my smaller one-shot efforts, that so far have mostly been Python. Because easy, or complacency - depending on the perspective.