Comment by xenophonf
4 days ago
> I have recently jumped onto the "write python tooling in rust" bandwagon
I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment management, including CI/CD pipeline maintenance, that much more complicated. It was already bad enough when I was trying to compile binary distributions on Windows, and that was just with the Visual C++ toolchain mess that is the Microsoft development experience.
(pyca/cryptography dev here)
As Steve notes, Rust does support s390x. Even prior to shipping Rust code, we never tested or claimed to support s390x.
If there's genuine interest in more people supporting s390x in the open source world, folks will need to do the work to make it possible to build, test, and run CI on it. IBM recently contributed official PPC64le support to pyca/cryptography (by way of Github Actions runners so we could test and build in CI), and they've been responsive on weird platform issues we've hit (e.g., absl not support ppc64le on musl: https://github.com/pyca/infra/pull/710#issuecomment-31789057...). That level of commitment is what's really required to make a platform practical, treating "well, it's in C and every platform has a C compiler" as the sum total of support wasn't realistic.
If you don't mind, how did you get into cryptography development? I have heard many say that don't do this unless you're experienced but I wonder how one becomes more experienced if you don't do it by yourself.
Note that Python, in 2022, adopted a "target tier policy" based on the one I wrote for Rust in 2019. (See https://doc.rust-lang.org/nightly/rustc/platform-support/s39... .
Rust supports s390x. https://doc.rust-lang.org/stable/rustc/platform-support/s390...
On top of all this, pretty much everything depends on Python (even glibc's build system depends on it now), and Rust is relatively hard to bootstrap. So bootstrapping a usable Python on glibc could one day involve bootstrapping all the way up to Rust on musl (including e.g. llvm) just to get Python just to build the final system's libc.
That doesn't feel great to me.
please note that I am not talking about introducing rust into the python interpreter (where, I agree, bootstrapping concerns would make the gain in code maintainability not really worth it), but in writing developer tools that work with python in rust or a mix of rust and python rather than in pure python. these are tools that run on the developer's machine or on test/ci servers, not in the target environment.
I can sympathise with that, but to argue a bit for the other side, these tools are mainly intended to run on the developer's machine or in the CI pipeline. in both cases they overwhelmingly use architectures that rust supports, and in the case of CI surely it's easier to deploy a single rust binary than a python binary and all its library dependencies.
I used to be very much in the "write your language tools in the language and the community will contribute" camp, but astral has really shown what a big difference pure speed can make, and I now have more of a "write tools in rust and ideally make sure they also expose libraries that you can call from python" mindset.
Visual C++ toolchain is rather easy to install, the issue is briging other OS expectations to Windows, likewise the other way around.
However I fully agree with you, the tooling for a given language should be written in the language itself, and it is an ecosystem failure when it doesn't happen.
I also feel that this trend, as usual, is people building their portfolio in the current trendy languages.