Rust v10 Patches Posted Ahead Of Expected Merging With Linux 6.1

[marios]

Good luck finding some then. I had a proper psychologist-administered IQ test as a kid and it was somewhere in the 160s so I'd just be a disappointment to you.

Thanks for the argument in favour of my "IQ is bullshit" theory.

[ssokolow]

Thanks for the argument in favour of my "IQ is bullshit" theory.

Point. Maybe I am an idiot. I'm still wasting time responding to you. Bye.

[ssokolow]

You can try and retrace my steps to get the gist of what I was going through back in March 2020. I don't remember, because I have better things to remember than being angry and confused.

1. Download Firefox 68 source code, or any browser based upon Firefox 68. That was the latest version of Firefox codebase for that particular Firefox fork. Not my choice, not my call, except I wanted that in some distro I like.
2. Get your Firefox build dependencies. Among them, you must give a try to different versions of Rust compiler from 1.31 to 1.41. You'll notice that as you rebuild Firefox 68 with newer and newer versions of Rust compiler, you will get more warnings. At Rust 1.33, you should start seeing your first compilation errors. You can write patches to make it work, and those patches should carry you all the way up until Rust 1.37. Once you enter Rust 1.38, you should again get compilation errors.
3. You may wonder why did I put Rust compiler 1.41 up there in the range in step 2. It's because the distro I made it for is a rolling release distro and at some point, we have dropped Rust 1.37 and there was no way of going back other than:
A - dropping this Firefox fork
B - patching this Firefox fork to work with Rust compiler's whimsies, because it would be an insult to call it sober design decisions to break backwards compatibility so non-chalantly like Rust just did
C - preserve Rust 1.37 as a compiler, even though it should not be installable if upstream of the distro decided to drop it for all the right reasons

Since Rust has already ruined package maintainership for me with its inconsequential development, I am very right to be worried that the same exact analogous situation will happen to other people. I also have the right to indefinitely hold a grudge against Rust because it ruined a hobby for me.

That's not Rust's fault. That's "Firefox developers decided to do the equivalent of depending on out-of-tree GCC patches". Each version of Firefox specifies a specific Rust compiler they expect, because they depend on experimental language and compiler features that have not yet been stabilized and are only implemented as draft proposals. (And, for that matter, will refuse to compile outside the nightly release channel for rustc unless you abuse a hidden environment variable meant for widening the range of compiler builds that can be used to compile new compiler releases.)

Hypocritically for the Firefox devs, a rustc design decision decision inspired by how browsers now only allow access to experimental CSS on nightly-channel builds because everyone wound up relying on vendor-prefixed experimental things that weren't supposed to be stabilized yet.

[rmoog]

That's not Rust's fault.

Oh dear. Look, I don't want to be an asshole, but I've heard this argument so many times it begs the question if Rust doesn't suffer from narcissism. More on that later, I don't want to make a red herring out of this. Let's say I have GCC 4 through 9 and an arbitrary C project. What's gonna most likely happen is most of the builds will not fail. That is the kind of support I expect from Rust if Rust wants to compete with C.

That's "Firefox developers decided to do the equivalent of depending on out-of-tree GCC patches"

Excuse me, the patches I mentioned were fixing Firefox code written in Rust language, so that it compiles with newer Rust compilers. Not Rust compiler code fixed up to conform to this version of Firefox. I just want to make sure we have this clear, it's easy to misunderstand. I get the feeling I might have been misunderstood because you're now talking about patching GCC. That's a bit extreme to do for 1 package.

Each version of Firefox specifies a specific Rust compiler they expect, because they depend on experimental language and compiler features that have not yet been stabilized and are only implemented as draft proposals.

Hmm. That means there should be no problem if you upgrade rustc. Why does it cause problems then?

[NobodyXu]

Hmm. That means there should be no problem if you upgrade rustc. Why does it cause problems then?

IDK why firefox failed as I didn't try it, but could it be that they are depending on nightly features that changed for better or removed?
That is the first thing comes to me mind.

Otherwise, upgrading rustc usually don't cause any problem.
New version does deprecate a few APIs and if you performs some UBs in your const code, the latest rustc (1.64.0) would catch them on declaration rather than giving an error when using them.

There's also recent upgrade to socket API, using rust native types instead of libc ones, which breaks code that makes assumption on their layout (which is an implementation detail) and use transmute to cast libc types to std socket types, but the std teams have submit patches and worked with important crates that contain such code to fix the issue.

That's all the recent breakage I heard, none of them seems to be breaking correct code using stable features.

Of course, if firefox uses nightly feature, then it can changed between version since nightly is meant for testing out these unstable features until they reach stability.

[rmoog]

So the red herring. This one has to do with some really toxic attitudes in the Rust developer community. ssokolow I'm bringing this up, because "this isn't Rust's fault" that Rust fails to maintain stability from one release to another reeks of lack of Rust's responsibility for its own actions.

Just take a look here, distance yourself from Rust advocacy and Rust hating for a moment, and consider these posts:
1. https://github.com/pyca/cryptography...ment-775016788
2. https://github.com/pyca/cryptography...ment-775028182
3. https://github.com/pyca/cryptography...ment-775041677
4. https://github.com/pyca/cryptography...ment-775970400
5. https://github.com/pyca/cryptography...ment-775974017

Here's my takeaway. You can expect Rust fanatics to:
- refuse to cooperate with others (1)
- acknowledge no consequences of their whimsy and even firmly believe they've done the world a favor because their misdeeds were done for all the good reasons (2)
- live and code in an echo chamber of mutual affirmations, completely detached from reality (3)
- brush off real-world problems with ivory-tower academic rants (4)
- insult other people (5)

If this continues on, we can expect the "Code of Conduct 2: Electric Boogaloo" to happen, because those people are one day going to insult the wrong person at their workplace. I think it's time to stop, it's time to make Rust a stable language if it's gonna be used, and a good start would be to reduce its build-time dependencies. LLVM and Clang take ages to compile, GCC takes much less. I don't see anyone complaining about Python or Perl and the reason why is because every C compiler can compile them, not just Clang, which brings down the build-time of Perl and Python to 10 minutes versus a couple of hours of building Rust, provided you have LLVM and Clang prepared ahead of time.

[NobodyXu]

If this continues on, we can expect the "Code of Conduct 2: Electric Boogaloo" to happen, because those people are one day going to insult the wrong person at their workplace.

TBF, that kinds of toxic behavior happens everywhere...
It's people's nature, nobody knows how to fix that.

I think it's time to stop, it's time to make Rust a stable language if it's gonna be used, and a good start would be to reduce its build-time dependencies. LLVM and Clang take ages to compile, GCC takes much less.

Checks my reply, according to my knowledge rust is very stable if you don't use any nightly feature.
If firefox use nightly feature, then it's unstable because these features are not stablised yet and are subject to change.

If you want to use a old rustc, you can always use rustup, it contains all historical releases and installing any version is just downloading it from their archive.

[ssokolow]

Oh dear. Look, I don't want to be an asshole, but I've heard this argument so many times it begs the question if Rust doesn't suffer from narcissism. More on that later, I don't want to make a red herring out of this. Let's say I have GCC 4 through 9 and an arbitrary C project. What's gonna most likely happen is most of the builds will not fail. That is the kind of support I expect from Rust if Rust wants to compete with C.

...and they do... to the point of having a bot named Crater which lets them test changes against some/all of the libraries uploaded to crates.io... but only if you actually stick to what they promised to keep stable.

Excuse me, the patches I mentioned were fixing Firefox code written in Rust language, so that it compiles with newer Rust compilers. Not Rust compiler code fixed up to conform to this version of Firefox. I just want to make sure we have this clear, it's easy to misunderstand. I get the feeling I might have been misunderstood because you're now talking about patching GCC. That's a bit extreme to do for 1 package.

With GCC, experimental changes to the language don't make it into the release builds until they're considered API stable. With Rust, to make it easier to get feedback, those changes are available behind special switches on the nightly channel in the main repo with the understanding that they might change or go away in the future. It's like how Firefox and Chrome have experimental flags you can flip on to test out potential new features, but you're not supposed to write public-facing websites that depend on them.

The Firefox developers are saying "Use this version of Rust and let our build scripts flip these switches to build successfully", which is the Rust equivalent of "Take this version of GCC and apply these patches to build successfully".

Hmm. That means there should be no problem if you upgrade rustc. Why does it cause problems then?

Because Firefox is intentionally depending on experimental language features not promised to be forward compatible and only intended for letting developer test out proposed extensions to the language. It's like websites relying on -webkit-prefixed CSS, except that the Rust developers refuse to be pressured into de facto standardization.

Firefox is a glaring exception to what's normal for Rust-using projects and hypocritical given that, unlike Chrome, Firefox requires you to download a completely separate build to do things like installing unsigned extensions.

[ssokolow]

So the red herring. This one has to do with some really toxic attitudes in the Rust developer community. ssokolow I'm bringing this up, because "this isn't Rust's fault" that Rust fails to maintain stability from one release to another reeks of lack of Rust's responsibility for its own actions.

Again, Rust has no responsibility to freeze experimental DRAFT language features the instant some jerk starts depending on them in a shipping product, just because that jerk happens to be a browser developer.

We don't hold GCC or LLVM-Clang or MSVC to that standard and Firefox devs, being responsbil people, don't depend on draft extensions to C++ the instant some combination of compiler flags will induce some version of GCC to produce the desired machine code from them.

Just take a look here, distance yourself from Rust advocacy and Rust hating for a moment, and consider these posts:
1. https://github.com/pyca/cryptography...ment-775016788
2. https://github.com/pyca/cryptography...ment-775028182
3. https://github.com/pyca/cryptography...ment-775041677
4. https://github.com/pyca/cryptography...ment-775970400
5. https://github.com/pyca/cryptography...ment-775974017

What do posts by two members of the Python Cryptography Authority (not having any authority to set Rust team policy) have to do with whether Rust is good or bad? That's like blaming Microsoft for decisions Linus makes because they use Linux in WSL.

Also, as a developer myself, I sympathize with the post Weird architectures weren't supported to begin with. Just because you induced my code to build on some platform I've never heard of doesn't automatically obligate me to suddenly constrain my decisions about what to do for the good of the platforms I did make a conscious decision to support.

Here's my takeaway. You can expect Rust fanatics to:
- refuse to cooperate with others (1)
- acknowledge no consequences of their whimsy and even firmly believe they've done the world a favor because their misdeeds were done for all the good reasons (2)
- live and code in an echo chamber of mutual affirmations, completely detached from reality (3)
- brush off real-world problems with ivory-tower academic rants (4)
- insult other people (5)

That's so divorced from what I've observed, even in the things you linked, that I'm going to say [citation needed] before seeing it as anything but you projecting your own biases on others.

I think it's time to stop, it's time to make Rust a stable language if it's gonna be used,

It is a stable language... as long as you don't do the equivalent of including "apply these patches to GCC" as part of your build instructions like Firefox does.

and a good start would be to reduce its build-time dependencies. LLVM and Clang take ages to compile, GCC takes much less. I don't see anyone complaining about Python or Perl and the reason why is because every C compiler can compile them, not just Clang, which brings down the build-time of Perl and Python to 10 minutes versus a couple of hours of building Rust, provided you have LLVM and Clang prepared ahead of time.

Work in progress:

• https://blog.antoyo.xyz/rustc_codege...ress-report-15 is an effort to adapt the current rustc frontend onto GCC, writing patches for GCC along the way to expose the necessary APIs to do so. It's making impressive progress.
• https://rust-gcc.github.io/ is a separate effort to write a Rust compiler in C++ with the intent to upstream it into mainline GCC.

[ssokolow]

Poke poke. Unapproved reply number 49.

(Also, please excuse the typos I can't fix, no thanks to how vBulletin locks unapproved posts and re-unapproves posts if they get edited after approval... and, in hindsight, I got the names the wrong way around for making the correct point in "That's like blaming Microsoft for decisions Linus makes because they use Linux in WSL.")