Re: the problem of rust :-(

[pin <voidpin%protonmail.com@localhost>]

On Wednesday, June 5th, 2024 at 3:08 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:

There's soo much in here that, it's best to edit an answer in a text editor :)

> There is new rust in wip

Which works flawlessly on amd64 and builds a working, not only Firefox, but. the whole of my system.


> but updating to it would mean desupporting
> some platforms. Thus the question is how to proceed (post 2024Q2 but of
> course we can debate that over the next 3.5 weeks).

Before we go imto the options, there's an important factor ro consider.
I've tried to discuss it several times but, it seems it remains ignored.
Personally, it's not that important but, it does affect the whole structure.

Remember 2021?
Rust "editon = 2021" was introduced, soon after most things required Rust >= 1.56

This year is the year of "edition = 2024" and, altough this hasn't been set yet, it looks like "edition = 2024" will require Rust >= 1.82

This means, that nothing stating "edition = 2024" will build with Rust < 1.82, just like in 2021.

> It seems options are:
> 
> 1) fix rust so it works on all platforms it works on now

Unlikely, although for obvious reasons, this would be the prefered option.


> 2) decide to give up on some platforms, withdrawing significant
> amounts of software, and basically turning the hardware into ewaste

I'm against ewaste but, honestly it was ages ago you could walk into a retailer shop and walk out with a 32bits machine.
Add to this, that many projects refuse to support 32bits, this is independent of Rust.
There are several Go packages failing to build on 32bits.


> 3) see if the issue is buiding vs a built rustc working, and pivot to
> rust-bin that is cross built as the appraoch for some platforms.

I think he@ has showned that cross compiled compilers fail to produce working binaries in some cases.
But, I'll leave this for a more qualified answer.


> 4) version rust, so that the older version is available when the newer
> one isn't. That also decouples getting it working from newer on
> platforms where it is less troubled.
> 
> Probably, we'd strive to aggressively add versions, and gc versions
> that are not needed for some platform. Call the oldest necessary
> version the floor version.

This will only buy us a few months, see comment on the release of "edition = 2024".
Basically, one will have a working compiler that cannot compile anything, because, all software will require a higher version of the compiler than the one provided by the system.
What do we do then? Version every program also?

 
> This implies marking packages with required rust version, but we do
> that already.

In maybe less than 5% of the cases. Mostly, no.


> It then leads to this same problem happening with each
> rust-using program. Given rust culture, that's probably sooner rather
> than later. That it turn leads to
> 
> 4A) version rust-using programs, and keep the most recent one that
> builds with the floor version
> 
> 4B) don't version rust-using programs, so that when something
> doesn't build with the newest version on some platform, it just
> doesn't, leading to using a C ancestor

It's complicated but, again there is basically nothing that builds with Rust < 1.56.
This is only 3 years ago. Is it worthy?

> 5) Convince the rust ecosystem to value portability

Together with 1) this is the best option but, the lack of interest in fixing https://github.com/rust-lang/rust/issues/123551 doesn't look that promissing.
If, at least aarch64 would work ...


> Alternatively, convince people not to use rust unless their program is already so
> bloated that there is no incremental harm.

If it wasn't for Rust, we wouldn't have Spotify support, because without it you need Widevine (Google DRM shit).
Irrelevant? Maybe for some but, for me it's important. I've already offered video streaming from the major platforms.
I won't offer music as well.

/Pedro