LWN: Comments on "Rust-for-Linux developer Wedson Almeida Filho drops out"

What?

deepfire — Thu, 28 Nov 2024 20:06:35 +0000

> To me, a viable alternative to C, should it ever exist, should embody C's simplicity and spirit of empowerment

This makes me think that you still don't "get it" -- as mentioned by many, "C's simplicity" doesn't exist.

Tongue in cheek -- according to your definition of simplicity -- is assembly simpler or more complex?

If you agree, then why is your definition of simplicity a desirable goal?

If you disagree, then you must also disagree that C is simple.

Linux-for-Rust or Rust-for-Linux

deepfire — Thu, 28 Nov 2024 18:32:11 +0000

Thank you for saying the obvious!

Linux-for-Rust or Rust-for-Linux

sammythesnake — Wed, 11 Sep 2024 01:05:18 +0000

"Rose Tinted Spectacles are often that colour from blood spilled in those earlier times"

- Mark Twain*

* Not Mark Twain - I just made it up

WHAT?

Wol — Tue, 10 Sep 2024 20:37:29 +0000

> There doesn't appear to be a clearly defined charter here and that's part of the issue. You've chosen to scope it to just systems-level programming languages despite the fact that the Linux ecosystem makes use of many higher-level and lower-level languages. Worse yet, there is plenty of coverage on this site for a programming language like Python so even the scope you've opted for is wildly off-base.

It's Jon's site. He's part of the core linux kernel team (inasmuch as there is such a team). It's down to him what he cares to put in.

And that's why it's such a good site. I go on about PJ, but the charter for Groklaw was similar - if she wasn't happy with it, it got deleted. That's why it was such a damn good site.

Cheers,
Wol

WHAT?

corbet — Tue, 10 Sep 2024 19:21:27 +0000

Regardless of the goodness of the riddance, this seems like a good place to stop this subthread, please.

WHAT?

intelfx — Tue, 10 Sep 2024 19:09:19 +0000

> why I am likely not to renew

Is this the point where we are supposed to bow our heads in shame?

Recalling some of your comments on the recent Ladybird article... I'd say good riddance.

Calling Rust from C

farnz — Tue, 10 Sep 2024 19:06:31 +0000

Calling Rust from C is fairly well established outside the kernel, with cbindgen helping to reduce the amount of C-side boilerplate you have to keep in-sync with the Rust #[no_mangle] code and #[repr(C)] data structures.

I would hope that the Rust-for-Linux people would be willing and able to help you do a good job if you were trying to write in-kernel Rust that's called from C - adding in things like cbindgen to the build system to make your life as simple as possible.

WHAT?

rc00 — Tue, 10 Sep 2024 18:57:51 +0000

I didn't intend for this to become a long thread so I don't know how much more I'll reply but here goes.

> there's not much reason for LWN (formerly Linux Weekly News) to cover them.

There doesn't appear to be a clearly defined charter here and that's part of the issue. You've chosen to scope it to just systems-level programming languages despite the fact that the Linux ecosystem makes use of many higher-level and lower-level languages. Worse yet, there is plenty of coverage on this site for a programming language like Python so even the scope you've opted for is wildly off-base.

> it seems there was not enough interest among readers to continue.

And this is the modern challenge that content creation/distribution channels have to face. You either pander to a niche but terminally online vocal minority or you stick to some predefined ethos. The former strategy is a means for survival. The latter strategy means possibly ending up like AnandTech. I don't have the answer or any recommendations here. On my end, my attention and support are finite resources that I would rather focus where I deem they would have the most value.

> I see nothing "idiotic" in his comment.

Inane? Unsubstantial? Witless? We're just going to have to agree to disagree on this one. Maybe it's a problem on my end? I find myself having a shorter and shorter fuse with the pro-Rust crowd. Somehow, they managed to take the worst parts of the Apple fanboys and the Pythonista/Scala/Haskell hype phases and then exponentiated them into something far more toxic and all around worse. I cast aside any benefit of the doubt years ago. At this point, you can call it bias if you want. I would call it a defense mechanism, not unlike one I've developed for the crypto space. When something is off and off-putting, cutting through the chaff is a more than rational response to develop over time.

This ended up being much more than I intended to write so apologies are in order. I also can't see myself continuing this thread too much longer so apologies in advance for not carrying on with this as well.

If you can't join 'em...

mb — Tue, 10 Sep 2024 18:35:24 +0000

>or maybe you're saying that just about the compiler?

Yes, I was only talking about the compiler. Adding kernel support looks like a minor issue to me.
Of course it has to be done and as long as it hasn't been done it's a blocker of course.

>They also don't have a story for calling rust from C

The Rust code just has to provide an unsafe extern-C function to be called. That's it. There's nothing special about that. It's a Rust function that has normal C linkage.

>But even the rust people don't yet seem to advocate making rust a hard dependency for much if anything,

People need to understand why that is on a case by case basis.
I completely agree with you that it's not prime time for Rust-Wifi, yet. But that doesn't say anything about how much work is left to that goal. And *that* actually is the interesting question that can be used to make progress.

If you can't join 'em...

johill — Tue, 10 Sep 2024 18:01:16 +0000

> Arm32 has tier 2 support. It works pretty well (I use it).

The kernel doesn't support it, according to the rust documentation. Maybe that's outdated, or maybe you're saying that just about the compiler?

> Ok. Is that really a big thing? Should that block us? These are the questions I'd like to see.
> And yes, the answer *can* be yes, if there are facts that show this.

I have no idea. WiFi is pretty universal these days.

But even the rust people don't yet seem to advocate making rust a hard dependency for much if anything, so I think the point is moot. They also don't have a story for calling rust from C rather than the other way around, which would actually be the use case I'd first be interested in here to make some critical parsing code better.

WHAT?

rbtree — Tue, 10 Sep 2024 17:36:13 +0000

OK, I'm not the editor, but...

> Go ... and Clojure

Neither one is a good choice for system-level programming, nor a potential replacement for C in the most significant project this website is about ⇒ there's not much reason for LWN (formerly Linux Weekly News) to cover them.

Although they did cover PHP for a few months a couple of years ago, it seems there was not enough interest among readers to continue.

> idiotic echoes like the one above

You may have misunderstood mb. He blacklisted your future comments because the tone of that phrase is not appreciated; that is all. I see nothing "idiotic" in his comment.

(And yes, I did support LWN while I could, and would still be doing that if not for mindless carpet-bombing performed by certain individuals completely unrelated to this site. No hypocrisy on my end.)

If you can't join 'em...

mb — Tue, 10 Sep 2024 17:19:26 +0000

Arm32 has tier 2 support. It works pretty well (I use it).

Rust compilers work pretty damn well, even if they don't have the official tier 1 blessing.
I only hit a compiler bug once, so far. In a tier 3 architecture (esp32) a couple of years ago.

And it's not that all stable gcc versions support building the kernel.
The kernel history is *full* of gcc workarounds and banning some gcc versions from building the kernel.
That can easily be done with Rust as well. If there's a buggy version, just ban it. Or the other way around pin a known-good set of Rust compilers. (That's how it currently works, as far as I understand it). That has been done with gcc, too.

Based on that, I think arm32 should not be a blocker.

We need to apply the same basic rules for gcc, clang and Rust.

>SH enables wifi in the defconfig too.

Ok. Is that really a big thing? Should that block us? These are the questions I'd like to see.
And yes, the answer *can* be yes, if there are facts that show this.

>USB device support is probably pretty universal across architectures.

Yes. But IMO that doesn't mean we should support users who stick an USB host controller into an Alpha machine to put an USB wifi into it.

>saying "you were always against rust, so you just pretend you care about architectures"
>is the wrong way to go about this.

Yes, correct. This is wrong to say.

"you do" and "you just" sprinkled with "religion" and "you force me to..." is the biggest problem in this whole discussion. And it's also not limited to the kernel. I saw this exact same behavior in completely different contexts, too.
It's unprofessional.
We all need to calm down a bit and get back to talking about facts.

If you can't join 'em...

johill — Tue, 10 Sep 2024 16:49:29 +0000

I'd think ARM (32-bit) and MIPS are still relevant in routers, and MIPS is just getting an initial rust support as we speak.

SH enables wifi in the defconfig too.

USB device support is probably pretty universal across architectures.

Anyway, I'm just pointing out that saying "you were always against rust, so you just pretend you care about architectures" is the wrong way to go about this.

If you can't join 'em...

mb — Tue, 10 Sep 2024 16:14:59 +0000

Well, what actually are the platforms that support wifi today and at the same time don't have Rust compiler support today? That data is what I am missing for a judgement whether it would be a big regression.

With wifi support I mean you must actually be able to put a wifi device in there and use it.

Then we have a base for judging whether we should care about those users or not.

If you can't join 'em...

johill — Tue, 10 Sep 2024 14:58:00 +0000

I'll ... try to actually take this on good faith, I guess?

Your previous comment is implying that e.g. me saying I need to care about platforms that Linux supports today etc. is actually just being done in support of my pre-conceived notion that rust is bad and not going anywhere etc.

Do you actually think that helps rust's cause? Because if so I think this thread simply ends here, there's nothing I can say to that.

On the other hand, maybe you're just confused? I don't have a _choice_ to care about platforms. I'm not going to be in a position to say that from this day on WiFi simply doesn't work on any platform without rust. That would be a pretty major regression, don't you agree?

Doesn't even matter if I like to use rust or if I think it's a bad idea, but like I said, implying that I say that just because I don't even want rust ... I feel your attitude probably isn't representative, and that can only be a good thing.

If you can't join 'em...

taladar — Tue, 10 Sep 2024 09:55:52 +0000

On the other hand you lose supporters much more quickly by insisting that your personal niche (e.g. keeping a platform alive that hasn't been in production for 20 years as a hobby) use case should trump every other priority in the project. In fact this kind of attitude might very well break the entire project if supporters wander off to form their own project without barriers like that instead of joining your project.

In a world of finite amounts of total effort available every bit of effort put into a project needs justification and so does every choice among mutually incompatible goals. The ratio of work generated to people who care to put in the work for every single decision is a big factor here.

WHAT?

rc00 — Mon, 09 Sep 2024 23:22:14 +0000

Editor, last Thursday, Go released two security updates and Clojure also released a major update. The only programming language release covered by LWN that day was Rust.

Combine that with idiotic echoes like the one above and you have the exit survey for why I am likely not to renew.

This isn't an indictment of you, your team, or your choices in coverage but it is clear that I am not your target audience. Best of luck.

Youth

0x3333 — Mon, 09 Sep 2024 19:26:27 +0000

I like Almeida's work, but this clearly has issues that will never be resolved. Linux is C, and will always be. Rust is still too young for such an adventure with such old people.

2nd Implementation tests the meaning of the specification

farnz — Sun, 08 Sep 2024 12:02:39 +0000

That's where two implementations of the test suite comes in handy, since you now have two separate groups of people who've read the specification and agree on what it means; where one test suite fails and the other passes, you need to resolve that by either fixing the specification, or getting the passing test suite to agree that they had a gap in test coverage.

DARPA's mission statement

farnz — Sun, 08 Sep 2024 11:57:56 +0000

That pretty much falls out from DARPA's mission statement. They exist to fund revolutionary technology that would otherwise fail to get funded, aiming for transformational change from every success, and eating a lot of failures in the process. Hence things like Silent Talk and TRACTOR - both high-risk projects, that would transform the world if they succeed.

And going back in time a bit, the ARPANET was a high-risk project when it started; at the time, communications was circuit-switched, and telecoms companies of every stripe were uninterested in taking the gamble to find out if wide-area packet switching could be made useful, when they were quite happy with circuits. Had DARPA not funded it, ARPANET would not have existed, and we'd probably not have any global packet switched networks, since there was a belief that the size of router buffers in packet switched networks would grow with the size of the network, disproven by ARPANET not needing large packet buffers.

Proper Community Engagement

LtWorf — Sun, 08 Sep 2024 10:16:45 +0000

That algorithm doesn't work.

Proper Community Engagement

mb — Sun, 08 Sep 2024 09:22:21 +0000

>Am I right in thinking that would be okay in unsafe code, provided the mutable reference never escaped the unsafe block?

The unsafe block as such doesn't give you rights to violate rules.
It gives you access to deref of raw pointers, but you still have to adhere to the rules.
It does also give you access to some unsafe intrinsics, which might be what you need.
But you can't simply put an unsafe block around your data race and then hope it's fine. It's still a forbidden data race.
So you can for example use an unsafe atomic intrinsic to avoid the data race.

Proper Community Engagement

Wol — Sun, 08 Sep 2024 09:13:35 +0000

> You cannot ever have multiple mutable references to the same array element (or any other object, for that matter), because the borrow checker forbids it (and if you cheat and do it anyway with unsafe code, it is immediate UB because of noalias). Without mutable aliasing, it's not possible for two different parts of the program to both think they own the Nth slot in the array at the same time.

The only reason I can think of that is a simple locking algorithm - write your pid into a variable, wait a timeout, if your pid is still there you have a lock. That obviously requires everyone to have mutable access to that variable.

Am I right in thinking that would be okay in unsafe code, provided the mutable reference never escaped the unsafe block? I can think of a couple of race conditions, so the unsafe block could lie to the compiler by accident, but the approach is sound if the implementation is correct?

Cheers,
Wol

2nd Implementation tests the meaning of the specification

intelfx — Sat, 07 Sep 2024 17:40:30 +0000

Or you can simply have one team write the compiler (and maybe the spec) and some other team to write the tests using the spec.

Proper Community Engagement

SLi — Sat, 07 Sep 2024 17:20:54 +0000

It's my impression of DARPA that if it's not a bit crazy, it's not a project for them. I don't know the numbers, but it sounds to me like they only take up things that are much less likely to succeed or not, and then one in 20 does.

2nd Implementation tests the meaning of the specification

jjs — Sat, 07 Sep 2024 17:10:09 +0000

That test suite can determine if one implementation meets what the spec writers interpret the spec to mean. It can't detect if the spec always means what the spec writers think it means (the wonders of human language). The purpose of a second implementation is to check that the wording of the spec actually only means what the spec writers think it means. I.e. catch unseen errors in the spec. Again, there's a reason IETF requires two independent implementations of an RFC before they declare it a standard.

Outlook seems bleak

SLi — Sat, 07 Sep 2024 17:02:23 +0000

I didn't mean to imply Rust has no benefit. I like the language; the "no new features" tried to capture the core of "rewrite" (or also refactoring). I just mean to say that in my experience management wants to see new features, not rewrites, and you will get pushback if you say something needs to be rewritten or refactored. Often that's good—sometimes (especially slightly novice) devs tend to imagine a rewrite as a quick silver bullet. But usually it's the engineers who push for a rewrite, not management.

Not that hard

khim — Sat, 07 Sep 2024 12:05:50 +0000

> most likely not paying attention to what the compiler is trying to tell them because the transfer experience with other compilers to Rust where understanding most error messages requires significant effort.

No, it's not that. Many (most?) developers these days act like “human ChatGPT”: they combine various pieces of code that look somewhat relevant to what they are trying to achieve (often with help of IDE or even, these days, LLMs), then they run the generated mess and when it, inevitably, explodes – they fix the most egregious bugs.

Rust blows that approach to smithereens: sure, compiler says that what you wrote is nonsense… and even shows some possible solutions… but you don't need all that, you need to make your program to run!

Disconnect can be pretty severe and both people who find Rust conceptually easy and people who find it hard often talk “past” each other.

P.S. Note: the fact that Rust is “conceptually” easy doesn't mean it's easy to learn to write programs in it. It's similar to snowboard, in some sense: incredibly easy and simple tool… yet one that requires quite a non-trivial amount of skill to use it. But linux kernel people are, actually, unique positioned to learn it, because many concepts that Rust enforces are, in reality, already in use in Linux kernel… only is come places there code that “violates it a tiny bit”… and Rust wants 100% compliance, not 99% compliance.

Proper Community Engagement

montj2 — Sat, 07 Sep 2024 01:38:58 +0000

To be fair, as one who spent years in the defense industry, "vague suggestion" is a signal. Nary a requisition shall be written in 2025 that doesn't respond to the rust signaling. It's going to be a good few years for underemployed rust enthusiasts to snag federal/defense contract gigs!

If you can't join 'em...

DianaNites — Sat, 07 Sep 2024 01:00:46 +0000

By that point the GCC Backend will likely be complete, and (unlikely) GCC's frontend might even exist by then. So long as the obscure platform supports GCC, it'll be fine. Lots of people do care about platform support and are working towards expanding it.

Two implementations - another benefit

jjs — Fri, 06 Sep 2024 11:46:40 +0000

Seen it in other projects. You get something that works. Someone else builds a clean implementation - and you start seeing the cleanup in the design/specs as you make the two compatible. Which, in the long term, helps both teams.

Not familiar with Rust, but it sounds like the efforts are having good benefits even without Rust being fully integrated.

Unmerged toy

da4089 — Fri, 06 Sep 2024 07:36:55 +0000

> Feel free to popularize a different term to describe such architectures.

"Heritage" is the usual respectful euphemism, I think?

Linux-for-Rust or Rust-for-Linux

SLi — Thu, 05 Sep 2024 16:04:53 +0000

Yes, this is a good way to put it. A lot of the template machinery in e.g. C++ is there precisely to support you in doing things safely. Sometimes it's a delicate balance between the maintainability of the machinery and usability of it.

Standardization - two independent implementations are good.

ralfj — Thu, 05 Sep 2024 14:28:23 +0000

> If you have a spec with defined behavior, and two implementations have different behavior, but meet the spec, you really have two choices, IMO

That's not what happened here. In this case, the C standard was unambiguous since at least C89: "If size is zero and ptr is not a null pointer, the object it points to is freed". Some implementations violated the standard, and somehow it was deemed better to introduce UB into tons of existing code than to fix the buggy implementations.

Such a hypothetical case could of course happen, though. IMO in that case you have a buggy (unintentionally underdefined) standard -- which happens and which needs to be dealt with reasonably well. If you have multiple different implementations of the standard, they are very hard to fix (other than by making the standard so weak that it encompasses all implementations), and that explains some (but not all) of the oddities in C. If you only have a single implementation, it is a lot easier to fix such bugs in the standard/specification by adjusting either the spec (to still have a *defined* behavior! just maybe not the one that we'd ideally have liked to see) or the implementation. These kinds of things happen in Rust fairly regularly. A big part of what makes this possible is that we have the ability to add "future compatibility" lints to Rust so that there's many months or even years of advance notice to all code that might be affected by a compiler change. I worry that with multiple implementations, this kind of language evolution will become even harder than it already is due to the added friction of having to coordinate this across implementations.

If you can't join 'em...

johill — Thu, 05 Sep 2024 12:31:31 +0000

I will just say - this is how you lose supporters, by declaring concerns to be invalid and only the result of pre-conceived hostility.

Not that hard

taladar — Thu, 05 Sep 2024 12:09:30 +0000

> Contrary to legacy languages the Rust compiler is your friend and guide when writing code and when learning to write code. It tells the programmer what is wrong, provides a hint and a link to detailed information about the problem and often also the actual fix for the problem.

Which is why, when someone claims that Rust is hard because you constantly have to "fight the compiler" you know they are doing something fundamentally wrong in their approach to the language, most likely not paying attention to what the compiler is trying to tell them because the transfer experience with other compilers to Rust where understanding most error messages requires significant effort.

Linux-for-Rust or Rust-for-Linux

taladar — Thu, 05 Sep 2024 12:04:49 +0000

The "simplicity" also makes it incredibly hard to write abstractions that actually fully take care of a problem so you don't need to waste mental capacity on it every time it comes up.

Linux-for-Rust or Rust-for-Linux

taladar — Thu, 05 Sep 2024 12:01:21 +0000

The flaw in that line of reasoning is that how easily something is expressed matters a whole lot more in programming, maintainability, readability,... than how possible it is to express it at all.

If you can't join 'em...

taladar — Thu, 05 Sep 2024 11:44:48 +0000

One thing is for certain though, in that potential future all those obscure platforms that aren't supported by LLVM that seem to be such a big concern for many of the existing Linux maintainers hostile to Rust will lose out anyway because none of the big companies funding development care about those either.

Standardization - two independent implementations are good.

taladar — Thu, 05 Sep 2024 11:41:36 +0000

Which is why there is an effort to develop a Rust spec but that still doesn't require a second implementation, just a test suite that checks if the one implementation conforms to the spec.