But does it work everywhere Python works? My main issue with this Rust move has always been compatibility. Python can be embedded and ran in a heck of a lot of places. What's the story when libraries that I may want to depend on are actually implemented in Rust and my target doesn't/can't handle the toolchain and there's no build target?

▲ hk1337 an hour ago | parent | next [-]

Python doesn't even work everywhere Python works. I am really starting to like and lean towards languages that compile to a binary instead of scripting languages like Python, Ruby, PHP.

It's nice that, as long as it's compiled for the correct architecture, I don't have to install the language to run the application.

▲ the__alchemist 6 hours ago | parent | prev [-]

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)

▲ skeledrew 13 minutes ago | parent | next [-]

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.

-flet.dev

▲ 3eb7988a1663 4 hours ago | parent | prev | next [-]

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).

[0] https://news.ycombinator.com/item?id=26097153

▲ galangalalgol 6 hours ago | parent | prev [-]

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

▲

vlovich123 6 hours ago | parent [-]

For what it’s worth the GCC backend for rustc is making progress and rustc more generally supports a lot of embedded stuff already

▲

galangalalgol 3 hours ago | parent | next [-]

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.

▲

kstrauser 5 hours ago | parent | prev [-]

How’s that GCC backend coming along? I could look it up, but I bet others would like to hear about it too.

	▲	vlovich123 an hour ago \| parent [-]
		https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-43 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.