"Python still does not address the issue of dynamic typing and the inability to test correctly"

This is wrong, you can enforce typing on Python (pypi: typeguard)

The only issue with Python is performance, which is only an issue if you need performance.

    > 1. Perl has a dense programming style and is quite opaque to new maintainers. You also have CPAN dependencies to keep track of.

You can write dense Perl code just like you can write dense Go, Rust, ... code (did you ever write a rust proc_macro and then wanted to edit/extend that like half a year later?); our common coding style in Proxmox is to not use the more sigil-heavy/dense variants of Perl. Re CPAN: that's not used at all in Proxmox VE; we distribute all packages and dependencies solely through Debian package based repositories, with full audit and supply chain integrity.

    > 2. Python is more readable than Perl, but has its own issues

See the first part of 1.; besides, both Python and Perl have type annotations that can help.

    > 3. Rust or Go is single-binary shipping. Rust or Go is easier to test.

Erm, no, that doesn't change anything? Our daemons are also just single executables. Just like you can "link" any interpreted code into one file, that can be OK for distribution but normally provides no benefit on its own. And they still load modules or dynamic libraries, like the stdlib; both Go and Rust are not fully static (as in compiled with musl) in most common use cases after all. For Rust this is actually a significant pain point: a good and stable Rust ABI that allows native dynamic linking would allow more library reuse and thus faster and smaller/more targeted updates for delivering bug and security fixes. As of now you always have to ship the whole (potentially huge!) binary to deliver an update. In some parts we use Rust dynlibs with a C ABI, but that's rather a crutch.

    > 4. In practical terms the Perl developer population is a shrinking one. Rust and Go are growing.

Yes, but that doesn't make Perl or Python a worse language to use, it mostly might hinder potential external devs from contributing. But for one, we have enough Perl experts hired to cover that, and for another, we know of one prolific former contributor with a ton of sysadmin and Perl experience that basically stopped contributing to our newer projects due to the Rust adoption and that being a challenge for them to learn. Language widespreadness also has to be looked at from the POV of the existing developer community, not just the global one. In this case the benefits of Rust still outweigh the cost, and it could also be the other way around, but it's still sad to see experienced contributors being hindered, and it's an example of your point not being as simple as it might sound.

    > Ultimately you are selling Proxmox as a hypervisor platform and the expectation is the user should not go hacking around in the shell?

Yes, that's also why I never stated otherwise, my point was that being able to do so is really not a negative thing. Or would Go or Rust become worse if they got better scripting support?

    > So shipping compiled binaries is safer (easier to audit) than shipping shell scripts that e.g. an attacker with shell access could easily compromise by manipulating the scripts.

For one, we're not shipping shell scripts, but polished Perl code with a mature module hierarchy and many modern features that Perl does provide over simpler shells like POSIX sh or Bash. And for another, no, binaries are not easier to audit, on the contrary; they are only auditable at all with reproducible builds, which is still not a fully solved issue (albeit we're getting there). Perl you can just look into, and debsums can also tell you at a glance that all files tracked by the Debian packaging system that we reuse are sound and safe, delivered and signed with our release keys. The latter holds for Rust too, that's why it's fine, but not because they are less introspectable due to being binaries. IMO you got it really backwards.

    > an attacker with shell access could easily compromise by manipulating the scripts.

An attacker with root access - which is needed to manipulate these "scripts" as you call them - can also just edit the binary, switch it out with a jump script/executable with their rootkit in there, or a recompiled version of the Rust, Go, whatever code with their malicious code in, ... Or how does being a binary magically avoid that?