I wouldn’t have bothered with a reply.

I have no idea how git works, not even the very basics, and still don’t

is arguably a worse look than

I constantly attempt manipulation and fail

anyway.

Fun because you like rewriting existing code?

Rust4Linux is not a “rewriting” endeavor.

Fun because you already have test suites you don’t have to rewrite?

See previous point.

Fun because you feel morally superior by writing fresh code, even though the old code is running critical applications in production?

Can you point to where “moral superiority” was used as a reason for using Rust in the Linux kernel?

Can you point to an example where Rust code in the kernel caused breakage in “critical applications in production”?

Bonus: Do you think “critical applications” closely follow mainline?

Fun because you think your smarter than the engineers that lay the ground work before you?

Who were the engineers that came before Greg Kroah-Hartman?

What ground work exactly are you referring to?

How does Rust code in the kernel relates to this?

Fun because you like hunting bugs you created thinking you know better, while calling your rewrite superior.

Better than whom?

What rewrite?

Where was it stated that the fun was in hunting more bugs?

Bonus: Do I actually prefer it if someone other than the original coder is hunting bugs?

And to finish with a meta question:
Why the likes of you feel the need to share opinions based on fictional events regarding matters your clearly completely clueless about?

OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

And that postulation is extra laughable because non-GPL coreutils implementations always existed. And by always, I mean they actually predate the GNU implementation itself (which was a originally a “rewrite” btw 😉).

And yes, they don’t target GNU compatibility, but some of them are perfectly serviceable as is (e.g. the freebsd ones), and adding GNU compat to them would have been infinitely easier than starting a Rust implementation from scratch anyway.

Another laughable aspect regarding the coreutils/uutils case in particular is that uutils didn’t even start as a corpo-driven or corpo-backed project. It was literally a Mozilla employee having fun in his free time, especially during Covid, and community contributions in the same vein. Rewrites of non-GPL projects (e.g. sudo) were ironically much better backed.

From my experience here and elsewhere, the people who make such stipulations don’t even know which licenses the core packages in their own systems adopt. Many of them don’t even know what these licenses’ provisions precisely entail. They just perpetuate some retarded circlejerk probably started by some clueless+malicious e-celeb that goes like:

linux distro -> C -> gpl -> not corpo -> good
rust -> not gpl -> corpo -> bad

Zig is too irrelevant, both technically and adoption wise, for anyone actually relevant to be fighting over it. The number of notable Zig projects went from 3.5 to 2.5 recently 😉. Hell, Zig probably has more adoption as a build tool, than as an actual implementation language (I would take it over CMake any day of the month tbf).

Hell, WIP languages experimenting with effect systems and/or similar next-gen concepts will probably hit v1.0 before Andrew thinks Zig is ready for a v1.0, which is in his forte, but no one should be holding their breath if they are not aware of some history and personality details. Since Andrew tagged Zig v0.1, the Rust project designed the edition mechanism, introduced three inter-compatible editions (four if you include 2015), and managed on-schedule ~66 1.n minor releases, and in the process grew into a semi-popular language impacting almost every corner of the industry.

now

Full-length encodes will take days to finish, and we are not talking single digits.

An almost, but not really, practical encoder will probably take at least a year of development before it’s ready.

And anyway, do end-users still care about codecs (beyond decoding complexity/hardware support)?

using Tor for universal, straightforward seeding of git repos.

That doesn’t sound right. Maybe design/implementation details would make it less nonsensical.

C implementation of radicle

Now this just sounds like a bad joke. Especially with the tor project itself spending all this effort to give us arti as a readily usable embeddable rust crate.

How many layers should I go through?

Here is a few:

• PR’s replaced patch sets. Patch sets have nothing to do with “strangers”. Both are the medium where review for a logical grouping of code changes takes place. There is no separate categories here.
• In most open-source projects, everyone involved is a “stranger” to others anyway, including co-developers if any.
• PR’s/patchsets are orthogonal to T*D/Trunk-Based/Team-focused development. How can this be missed is hard to imagine. I would have assumed everyone is aware of draft/wip/rfc PR’s, or dev/trunk branches. And tests need development alongside functional modifications anyway.

Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.

wrong
didn’t bother reading further

Here’s a 249-page book “just” about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it’s a terrible language? No

If that book was about a million ways of how to just use atomics in Rust, then yes, that would be potentially bad. But SURPRISE SURPRISE, it’s not. As you can see for yourself.

Not sure what you were getting at there. Even hard C++ copers don’t attempt to argue against the fact that C++ is huge, and not only that, it’s the biggest language around by an easy margin (this can be roughly and superficially measured by comparing spec sizes).

It’s not the size, but rather everything on top of it, and contributing to it, from general incoherence to bad design to countless misfeatures, that require non-trivial argumentation.

C++ and JS are objectively shit languages from the pool of used languages.

What you quoted is one of the many COPEs Bjarne used in his lifetime. Because unlike JS people. who admit that JS is shit that was originally hastily put together, Bjarne needs the C++ bureaucracy, and the facade of superiority (even if it only lives in his own mind), to keep going because he has nothing else to show for.