[bborud]

Primarily any language that can produce executable binaries. Preferably statically linked binaries so that you can ship a unit that will not depend on the state of the system you try to run things on.

(With disk and memory sizes, dynamically linked binaries aren't really as relevant anymore since the often trivial cost of size more than makes up for the nontrivial cost of having to fiddle around to make things actually work)

[packetlost]

Wasn't the original argument more about allowing the system to provide patches to shared libraries, therefore moving the burden of patching to sys admins instead of the developer of the package?

[hultner]

It's possible to produce a self-contained executable with Python, there's multiple solutions for this it's just not a part of the core language.

I agree that the situation isn't perfect in the python world but it's actively being worked on and I think PyOxidizer looks like one of the most interesting recent developments in this space: https://pyoxidizer.readthedocs.io/en/latest/

Some other alternatives (depending on your use case, e.g. target platform) are PyInstaller, py2exe, py2app, cx_Freeze, Shiv, PEX (basically tooling for native .pyz), XAR, Nuitka (compiles Python into a native binary), pyninst (creates windows installer), PEP 441 style .pyz (executable python archive, can easily vendor in dependencies). Then there's tools like fpm if you want to create packages for deb, rpm, FreeBSD, macOS .pkg, paceman, tar-archives, etc.

I've used some of these in enterprise settings building rich GUI-applications being distributed to end users who have no idea of what Python is and to whom underlying technology choices are invisible.

[bborud]

So with so many solutions to the same problem being made: which do you choose?

The thing is: for it to be useful people have to use it. And for people to use it nothing works better than one clear, idiomatic way.

If you have many solutions you often end up having no solution.