It won't work in those cases. Do you have explicit examples? I suspect this won't come up much as Rust has, IME, much broader target support. (Including platforms without a GPOS)
I can't come up with any cases where cpython would compile that rustc can't target. There are some more niche interpreters that can run on embedded stuff with no rustc support, but they are also subsets of python so it isn't like you can just pull a wheel file and expect it to work
It does, and rustc nostd already supports a lot of places cpython can't run, but the other way around is just non existent. Rustc can't and will likely never support ti dsps because they own the compiler and a long is 48bits. Dreamcast and other things with weird data sizes also are out.
They’re plugging away at it. A major milestone was getting unwinding to work. I’d say they’re getting quite close and it’s getting better and better. It’s usable for Linux kernel compilation I believe which unlocks Rust to be used for the non-driver components in the kernel.
The Python cryptography library switched out C for Rust which invalidated some platforms[0]. 2021 story, so not sure if anything has changed.
...Since the Gentoo Portage package manager indirectly depends on cryptography, ""we will probably have to entirely drop support for architectures that are not supported by Rust"". He listed five architectures that are not supported by upstream Rust (alpha, hppa, ia64, m68k, and s390) and an additional five that are supported but do not have Gentoo Rust packages (mips, 32-bit ppc, sparc, s390x, and riscv).
I'm using Flet for a major project, which includes iroh, and it's been hellish going because the only way was to use the Kotlin build for mobile support, where I've had to be patching things all over to get something reasonable. Burned a lot of time on it and it still occasionally breaks, while the Python parts have been generally solid. Initially I looked into converting the Rust to Python, but that's a non-starter because of the semantics.
