Hacker News Reader

Comment by skeledrew | Hacker News Reader

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?

View on HN

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.

I got to love scripting languages with at very least a proper JIT compiler, since the work a Portuguese startup, where we did too much "rewrite Tcl in C" kind of work.

Indeed we ended up weighting between rewriting the whole thing in something else, with .NET being the winner, as Microsoft partners we got early access to ongoing .NET builds, for those that would like to present their "rewritten in .NET" products alongside the .NET public announcement in 2001.

Since then for me, the role of scripting languages like Python, Ruby has always been to be better than what I would use Bash for, PHP is what my ISP has, and that is about it.

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

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

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

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.

This is so cool. That's going to be amazing when it lands.

It’s already in rustup for what it’s worth. Not sure what “when it lands” means but I’m sure it’s an ever moving goalpost.

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.

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

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

Reply on news.ycombinator.com