Rust doesn't belong in the Linux kernel; it's all about ideology

Rust in the Linux kernel has been a source of drama for quite some time now, and while I somewhat sympathize with both sides (pro-Rust and anti-Rust), I believe the fundamental problem is that both sides don’t really understand each other (although one side more than the other), and it’s not just the technical issue of how to better write a kernel: it’s much more that the entire worldview is different.

The latest chapter in the saga is the resignation of yet another maintainer because of the way one of the patches for Rust support was handled. But the issue wasn’t what was done or said by the leadership, it’s what was not done — that according to many in the pro-Rust camp believe should have been done.

In this article I’ll touch a little on the technical aspects of C versus Rust, but I’ll dive deeper on the difference in mentality of C advocates versus Rust advocates.

TRIGGER WARNING: this article contains political references, even though I’ll try to refrain from any value judgement, people who need trigger warnings will find my implications offensive.

Theory of mind

One important aspect in dealing with other people is understanding that different people think differently (something sociopaths have trouble with), and I’m not talking about superficial things like some people liking onions while others don’t, I’m talking about some people’s lack of inner monologue. In my experience conversing with other people, when I bring up the fact that I don’t talk to myself (and so do many people), many are baffled and can’t imagine how that is even possible. Same goes for many conditions, such as synesthesia, aphantasia, prosopagnosia, etc. You talk to another person and you assume they experience reality the same way you do, but that’s not necessarily the case.

I bring this up not because it’s an interesting conversational topic: it’s to raise awareness that not everyone thinks like you do. A Republican and a Democrat can look at the same issue and arrive to completely different conclusions. And in the year 2025 it’s clear that people who are “based” and people who are “woke” don’t see eye to eye.

We can try to treat everyone equally, and that might work in your group of friends (who likely think alike), or your workplace (if you work in a monoculture), but when you are dealing with people all over the world from all sorts of backgrounds, these differences in what you assume to be true do matter.

One example I can think of where ideologies clash is the concept of regulations: one side of the aisle believes all regulations are harmful and anything the government does is wrong, the other side believes regulations are necessary and nobody else can enforce them but the government. It doesn’t matter how eloquently you present the best arguments with evidence to support them, you are not going to change anybody’s mind because it’s entrenched in a worldview that is significantly different than yours.

I believe the same happens with C versus Rust. The C mindset is very specific and unlike most programming languages, the kind of people who not only know C but excel at C are very particular. Similarly the kind of people that advocate for Rust share a lot in common. Once you see the commonalities it’s pretty hard to unsee them.

In theory this should be a purely technical matter, but it’s not, and I’ll show clear examples.

Stereotypes

Stereotypes are always bad and influence negatively how we perceive people, we all know that… Except that’s not true.

In order for me to sell the idea of a “Rust guy”, first I would need to establish that such a thing exists in the first place.

Stereotypes are not always wrong, in fact, they usually are not wrong. Take for example “Asian students tend to be good at math”. Is that really incorrect? Statistics tend to be on the side of stereotypes.

There is a problem though.

Say Brian is a Chinese student, should you expect him to be good at math? Well, no, because that would be a misunderstanding of statistics, but most importantly: that would be prejudice. So the issue is assuming that because an individual belongs to a certain group, he must share all the characteristics that are typical of that group.

Progressive people would screech at the mere suggestion of a stereotype, for example “men tend to be physically stronger than women” — even though that is a fact — and counter with something along the lines of “Martha is stronger than most men”, which doesn’t contradict the claim, because the claim wasn’t about all women, just the majority of them, so of course there will be a minority for which the stereotype doesn’t apply.

In fact, some progressives will go as far as to say that there isn’t such thing as a “woman”, because all categories are invented and reality is so passé. But that’s another philosophical rabbit hole.

Let’s consider another stereotype closer to home “tech nerds often lack social skills”. Would you say that’s inaccurate? That isn’t to say that if you are a tech nerd you lack social skills, maybe you are a tech nerd with great social skills, but if so, you are in the minority.

And by the way, when you think of a “tech nerd” did you picture a girl? Maybe there’s a reason for that.

People on one side of the C versus Rust debate already know that stereotypes are often useful and not generally wrong, but people on the other side would protest at the idea of a “Rust guy” even being considered. Can you guess which is which?

Prescriptiveness

One way in which you can differentiate people is in the way they consider prescriptiveness versus descriptiveness. For example, if somebody says “you shouldn’t use the word literal in a virtual way”, that would be prescriptive, whereas somebody in the descriptive side would say “that’s just how people use the word literal these days”.

I’m not going to issue a value judgement on what view is more correct, I’m just going point out that one side focuses on what ought to be the case, while the other focuses on what is the case.

Take the conflict in Ukraine. Some people say “Putin shouldn’t be allowed to win in Ukraine”, but the reality is that what should happen and what does happen are two different things.

Another way to put it is that the descriptive side is pragmatic, while the prescriptive side is more idealistic.

And you can see these two ideologies play out not just in the Rust for Linux debate, but it happened for example in the purging of the word “master” from tech projects (Why renaming Git’s master branch is a terrible idea). You can have the opinion that nobody should use the word “master” in their projects because it’s offensive, that would be prescriptive, but… people are still going to use it regardless.

Who do you think is more likely to push for changing the name of a branch away from “master”? A C mind? Or a Rust mind?

I think the side that focuses on what ought to be the case is pretty obvious, but we’ll see why later.

Boomers

One aspect of the debate I often hear people bring forward is that C developers tend to be older, and older people tend to avoid change. Comments like “Rust is just the shiny language of the day” don’t help elude that perception.

But the reality is that while some developers might avoid new languages due to some prejudice, not all of us do that. I’m on the older side of the spectrum, yet I often try new languages just to see what’s out there (recently Rust, Go, and Zig).

So while this stereotype might indeed be true, it doesn’t apply to all of us.

I heard the same argument back in 2010 regarding GNOME 3: “you just don’t like new things”, which is complete bullshit. I like new things, if those new things happen to be good. The problem is that new things are rarely good.

Disregarding all new things because new things are rarely good would be a hasty generalization fallacy, but thinking that all older people dislike all new things is also a hasty generalization fallacy.

No, I did give GNOME 3 a fair try at the time, and the reasons I didn’t like it are still valid today for newer generations, it wasn’t because it was “new”.

When it comes to Rust not only was I open-minded, I actually thought it was a great idea. That probably has something to do with the fact that I still remember how bad I was at C when I started, and I remember I tried to use static analysis tools to see potential memory issues with some code, that’s as close to Rust as it was available back then. Writing the annotations needed for the static analysis was tedious, so I only did it as a proof of concept, but I saw the potential of writing some code in a strict way.

So you could consider me an atypical “boomer” (I’m actually millennial) who doesn’t automatically dislike new things, in fact, I liked the idea of Rust.

Shiny

When older developers say Rust is a “shiny language of the day”, that is not inaccurate, it comes from decades of experience where whatever was popular at some time didn’t remain popular very long.

I used to be with ‘it’, but then they changed what ‘it’ was. Now what I’m with isn’t ‘it’ anymore and what’s ‘it’ seems weird and scary. It’ll happen to you!

Abe Simpson

Will Rust remain popular in 2030? Maybe. Will it be in 2040? Only time will tell. Visual Basic was popular in 2000, that doesn’t really mean much.

A long time ago I thought D could be a fine replacement for C (I still do), but at the time my criticism that the lack of open source tooling was going to prevent it from becoming popular was completely ignored (apparently somebody finally realized that in 2024).

Not all of us are married to C, I would love a language that was like C, but better, unfortunately there isn’t one (that includes Rust, Go, and Zig). People who think otherwise are not experts at C. Only somebody who is exceptional at C can tell you if there is a fine replacement, and as I argued in another article: most people are not great at C, and that includes developers with years of experience writing C.

We have established that automatically dismissing new languages is a fallacy, but the opposite is also a fallacy: just because Zig is newer than C that doesn’t mean that it’s better.

This fallacy is called appeal to novelty and curiously it’s a fallacy progressives often fall into. In 2025 it’s common for people to state their pronouns in their bio (e.g. he/him), progressives would say that is good, because it’s new. Conservatives on the other hand would say that just because it’s new doesn’t necessarily mean that it’s good.

But it’s more than just a disagreement on what’s better, what progressives are most afraid of is being on the wrong side of history, so anyone who questions what is new is considered morally defective, because only bigots would want to be on the wrong side of history, right?

Except nobody knows the future. Eugenics in the year 1900 was considered progressive (Progressive Era), but just because it was new it doesn’t mean it was on the right side of history. Similarly I can think of a couple of progressive ideas in 2025 that are likely going to be on the wrong side of history.

Who do you think is more likely to use the phrase “the right side of history”? A C developer or a Rust developer. Do you think a C developer is going to feel a moral impetus to rewrite some code in C because it’s the right thing to do? Or is that more of a Rust thing?

Dead end

I mentioned that initially I thought Rust was a good idea, in fact, in the previous article I wrote about it I still gave it the benefit of the doubt, however, it all changed when I tried to write a simple linked list, which turned out to be impossible. There’s even an entire book devoted to the topic (Learn Rust With Entirely Too Many Linked Lists), and the short answer is: you can’t (at least not the version I wanted).

I don’t particularly care about linked lists, the only reason I started writing them in different languages was to compare simple data structures with how they are written in C (in which it’s dead simple), and a linked list is the simplest data structure I could think of. Unsurprisingly it turns out it’s not so simple in different languages.

If I can’t even write a simple linked list in Rust, I think there is no hope of writing the most complex data structures of linux in Rust.

Perhaps I’m wrong and it is actually possible to do everything linux does in Rust, that is a technical problem, and all technical problems can be solved. Maybe the Rust for Linux project causes some changes in the language, who knows.

The ultimate problem as I see it is not technical, it’s the attitude that is the dead end.

When I discuss with Rust advocates and mention the fact that you can’t write a simple linked list like linux does (intrusive doubly circular linked list), they say two things 1) “yes you can” (untrue), and 2) “you shouldn’t want that”. Typical “it’s not happening and it’s a good thing that it is” responses.

The moment somebody tells me “you shouldn’t want that”, I stop using their software. Period.

I shouldn’t need to explain why I want to do something, the software either supports it or it doesn’t. I can’t count the number of times I’ve asked for help on some chat only to be told I shouldn’t want to do that — with the assumption that I know less than they do. The last time I asked for help regarding shell scripting I was told I didn’t understand the POSIX standard, but they were so wrong even the Austin Group agreed with me and fixed the POSIX standard (defect report). Did this chat accept I was right? Of course not.

It is pointless to try to change the mind of somebody with an entrenched worldview, it would be as pointless as trying to change the mind of some family member who believes Donald Trump is Hitler.

Note that I’m not saying that Rust advocates are necessarily wrong (even though I have a very strong opinion on the matter because I think it violates the first principle of software), I’m merely highlighting the discrepancy in worldviews. Rust advocates see the fact that the language prevents certain uses as a feature, while C advocates see the inability to shoot themselves in the foot as a bug.

So even though technically the Rust language could be changed to allow certain uses that are widespread in C, it likely won’t change because the mentality of Rust developers is just different.

This is a clear example where ideology affects the language. Rust developers are fond of prescriptiveness: “you ought to not write linked lists”, where C developers are pragmatic: “linked lists work, so I’m going to use them”.

For reference linux uses more than 10,000 linked lists, and its implementation has been honed to perfection over decades, even taking into consideration prefetch instructions and speculative-execution vulnerabilities. For an overview of a recent attempt to improve the iterator see this LWN article: Toward a better list iterator for the kernel.

I know that Rust has a LinkedList structure in std::collections, but would that be available in the kernel? In linux there isn’t a C runtime, so there isn’t even malloc() available. I have written RISC-V bare metal C programs and my own kernel for x86 in pure assembly language, so I have some rough idea what a kernel would need. But even if the standard LinkedList was available, it likely wouldn’t perform as well as linux’s linked list implementation in C, and a driver would likely want to perform operations on an existing struct list rather than creating one of its own.

But I shouldn’t need to explain why I want to write a linked list in Rust, or that linux uses them ubiquitously, all that matters is that they can be easily done in C, and if a language is going to replace C, it should be able to do everything C does, that rules out Rust. It’s that simple.

I think Linus Torvalds is giving Rust the benefit of the doubt, just like I did, but he hasn’t actually written any real Rust code. The moment he does, he will quickly realize why it cannot be used as a replacement for C, just like I did.

What I’ve heard Rust advocates say is that linux is wrong in using linked lists in the first place. Right… because Rust advocates (many who likely aren’t even that good in Rust) know better than the best C developers out there, including Linus Torvalds.

I’m actually working on a project to show with evidence why linked lists make sense in linux, which is not as easy as it sounds and it will take time to complete, but I shouldn’t need to do this, Rust people should consider the possibility that perhaps linux experts do know what’s best for linux. And of course even if I show with numbers why linked lists do make sense, Rust advocates are still not going to accept that reality, because that’s what people entrenched in an ideology do.

It may seem that I’m attacking Rust people, but I’m not (yet), you can easily argue that C people are entrenched too.

I believe there’s a reason linux uses linked lists, and they have considered different data structures, but it could easily be the case that my investigation proves otherwise, and Rust advocates are correct, we’ll see.

Example

In my previous blog post I used a very simple example of structure initialization to show how C experts write C code (linux style using C99):

struct person { char name[50]; int age; struct person *boss; }; struct person john = { .name = "John Doe", .age = 25 };

How does the equivalent look like in Rust? (I’m no Rust expert, so take this with a grain of salt)

struct Person<'a> { name: &'a str, age: u32, boss: Option<&'a Person<'a>>, } let john = Person { name: "John Doe", age: 25, boss: None };

Although superficially that doesn’t look particularly bad, as a C person this makes my eyes bleed. Let’s leave aside the headache of specifying the memory management in the declaration of the structure in a convoluted way, and the fact that all members of the structure have to be specified (in C unspecified members are all zeroed), the real issue is that this structure is tied to the stack, if you want to create the same data but dynamically on the heap, you would need a completely different structure declaration. In C the same declaration can be used both for the stack and the heap, and this is used all throughout the codebase of linux, and in fact it can also be used for static variables which can be modified. In Rust if you want a static variable that can be modified you would need yet another definition (in fact I don’t think you can do it “safely” at all).

In C mixing heap, stack, and static data is straightforward and very useful for performance reasons in linux (and probably any kernel).

Just thinking of how to mix the simplest structure I could think of in Rust is giving me a headache.

In fact, I can already foresee the retort from Rust advocates: “you should not want to do that”. Right… but I do, and so do linux developers.

Rust’s prescriptive nature is simply not a fixable issue.

Drama

Now that we have some rough understanding of the typical Rust mentality and the typical C mentality, let’s see how that help us parse the latest episode in the telenovela.

• Rust: they like to be told what to do and tell other people what to want
• C: they don’t like to be told what to do and have a laissez-faire attitude towards other people

Another way to put it is that Rust people tend to be prescriptive and law-abiding, while C people tend to be pragmatic and rogue.

Don’t force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that’s not C, be that assembly or rust you write to C interfaces and deal with the impedence mismatch yourself as far as I’m concerned.

…

If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

Christoph Hellwig

Christoph is telling it like it is. By saying that Rust is some people’s “shiny language of the day”, he is suggesting other people are appealing to novelty (it’s new therefore it’s good), which they are. He isn’t going to automatically buy that, which is reasonable. He also wants to contain the cross-language issues to specific drivers, he is using the word “cancer” as a metaphor for something undesirable that he doesn’t want spread.

But because certain people (i.e. progressives) have a visceral repulsion to certain words (like “master”), we can already foresee who is going to have a problem with using a negative word like “cancer”.

Now, I don’t personally understand Christoph’s objection, I don’t see how adding some utility code that all Rust drivers could use is particularly troublesome, but then again I don’t need to understand. Remember I started this article mentioning theory of mind? Well — unlike some people — I do understand that Christoph has a mind of his own, and I don’t know everything that he does, so he is entitled to having and voicing his opinion. Just because I don’t understand it doesn’t mean he is necessarily wrong.

What matters is if Linus Torvalds understands Christoph’s rejection.

At last year’s LPC I held a talk [1] about Rust in the kernel and there was a question at the end where I was asked how I think about cases where Rust abstraction break caused C API changes.

My answer was that I’m not too concerned about this. We can just rely on what already happens every day in kernel development: people work together and collaborate. There are a lot of very core components that are widely used and depending on the complexity of the change may require the help of the users to integrate changes. So, I don’t think with Rust abstractions we’re adding anything that the kernel does not already has a strategy to deal with.

Danilo Krummrich

This looks like a reasonable take, except that it’s wishful thinking. While it’s true that sometimes people in the Linux project collaborate, that’s not always the case. What happens in reality many times is that one developer who is updating an API updates all the instances in which that particular part of the API is used. This is possible because he knows C and all the code is in C. No collaboration necessary. If this API is used in Rust bindings, he wouldn’t be able to update that code, which could create unnecessary friction.

If I’m not a linux developer and I know that, how is it that Danilo doesn’t? I believe he does, but he has a prescriptive mentality and is focusing on what ought to be the case (in his opinion), rather than what is the case.

My 2c: If Linus doesn’t pipe up with an authoritative answer to this thread, Miguel and the other Rust folks should just merge this series once it is reviewed and ready, ignoring Christoph’s overt attempt at sabotaging the project. If Linus pulls it, what Christoph says doesn’t matter. If Linus doesn’t pull it, the R4L project is essentially dead until either Linus or Christoph make a move. Everything else is beating around the bush.

Rust folks: Please don’t waste your time and mental cycles on drama like this. It’s not worth your time. Either Linus likes it, or he doesn’t. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they’re going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.

FWIW, in my opinion, the “cancer” comment from Christoph would be enough to qualify for Code-of-Conduct action, but I doubt anything of the sort will happen.

Hector Martin

This response is so archetypical of a progressive mind that it is comical.

First of all, Hector is demanding an authoritative answer (didn’t I say Rust people like to be told what to do?). This view is not only at odds with how the Linux project works, but it’s also at odds with reality. Linus is the dictator, yeah, but even dictators like Augustus Caesar did have to consider the opinion of their people (otherwise he could be assassinated like his great-uncle). So why would Linus ignore Christoph’s opinion?

The established process of the Linux project allows everyone to voice their concerns and reject changes for a reason. Of course Linus can decide to ignore Christoph’s opinion, even the opinion of most linux developers, but it would be best if the project itself reached a consensus so Linus doesn’t have to step in. Only somebody with a prescriptive mind would prefer decisions to be made from the top down.

Also, Christoph is not engaging in an “overt attempt at sabotaging the project”, it’s effectively in the Linux by-laws that he as a maintainer can issue a nack whenever he feels like it’s warranted. You can dislike the process all you want, but that is the process.

Ironically progressive people boast themselves about being “inclusive”, but the second somebody expresses an opinion they vehemently dislike, they immediately segregate that person and anybody who thinks like him. This isn’t unlike COVID-19 shots, where progressives felt anybody who didn’t take them was despicable and deserve to die. It’s not very inclusive to wish people with a different opinion to die, if you ask me.

I’m not making a value judgement on COVID-19 shots, but it’s a fact that bodily autonomy is a fundamental right and a fundamental principle of medical ethics. But screw principles and deontological ethics when people hold opinions you really really dislike, am I right?

If on the other hand you value basic principles like freedom of speech, you would strive to tolerate even opinions you abhor, which means Christoph should be allowed to express his opinion as strongly as he desires.

I don’t think I need to spell out which side tends to be opposed to freedom of speech (I don’t even think they know what it truly means).

Hector also objects to Christoph’s usage of the word “cancer” in the most uncharitable way possible, even calling for a Code-of-Conduct violation. A progressive engaging in tone policing and weaponizing a Code-of-Conduct straightway (which by the way is the only way CoCs are ever used: to silence and get rid of the “undesirables” [something a certain unnameable journalist has written about extensively — his name starts L… and ends with unduke])? What a surprise. In fact it’s so common I think there should be a word for it: “cocfare” seems right (a portmanteau like lawfare).

But the cherry on top is invoking the wrong side of history: “they know they’re going to be on the losing side of history sooner or later”. I don’t believe they know that, and unless Hector has a crystal ball, I don’t believe he knows either. But let’s be charitable and suppose Hector is right and the Rust for Linux project ends up being a tremendous success in the near future. So what? That wouldn’t invalidate Christoph’s opinion. That would be like someone saying “I don’t want Trump to be elected”, and because Trump got elected, that means he was wrong? No. But even if Christoph was somehow wrong, so what? Since when are developers not allowed to make mistakes?

But what is even worse is equating a different opinion to immorality (just like progressives did with COVID-19 shots). If you believe Christoph is technically wrong, that’s fine, you are entitled to your opinion, but why must progressives jump from technically wrong to immoral?

I’m going to insert some value judgement here: the reason is that they can’t even conceive the possibility that they might be wrong. They are so certain that they are unquestionably right that they believe any action is justified because ultimately it will be vindicated. Just like a police officer planting evidence because they “know” for a fact the person is guilty, therefore bypassing the established process especifically designed to avoid biases like a police officer’s opinion. This view is technically known in philosophy as consequentialism. This is why it’s so effortless for them to invoke “the right side of history”, which obviously they are always on.

And finally: “no amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages”. Is that a fact? I would love to peek into Hector’s crystal ball. I’m not saying he is wrong, he might actually be correct, but I wouldn’t be so sure about the future, and I don’t think any reasonable person should. But let’s again suppose he is right, why does he have to deride people with a different opinion? What happened to inclusiveness and tolerance?

And there’s of course the possibility that he might be wrong. All things being equal I of course would prefer a memory-safe language over a language that isn’t memory-safe, but that’s the whole conundrum: are all things being equal? I don’t think so. I don’t think Rust can do all the things C can do, and so do many linux developers. Memory safety is just one of the considerations of good code, but it’s not by any means the only one.

But so far I’ve hinted only to two camps: pro-Rust and anti-Rust, while there’s a third camp: people who are neutral about Rust. They are on the sidelines just waiting to see how it all plays out. And I would venture to say it’s not looking great. Rust advocates are setting up the rules of the game so that if the Rust for Linux project is a success, that proves Rust is great, and if it doesn’t succeed, then it’s the Linux project’s fault. Essentially they cannot lose. I don’t think a rigged setting is going to convince anyone.

And of course it’s “old entrenched maintainers”: us boomers just can’t see how great Rust is. How is that not prejudice and hasty generalization?

If shaming on social media does not work, then tell me what does, because I’m out of ideas.

Hector Martin

Once again more consequentialism: the end justifies the means because there’s no way a progressive like Hector could possibly be on the wrong side of history.

Sanity

Let’s end with a based take:

How about you accept the fact that maybe the problem is you.

You think you know better. But the current process works.

It has problems, but problems are a fact of life. There is no perfect.

However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

Because if we have issues in the kernel development model, then social media sure as hell isn’t the solution. The same way it sure as hell wasn’t the solution to politics.

Technical patches and discussions matter. Social media brigading – no than\k you.

Linus Torvalds

A-fucking-men.

Linus is bringing up the fact that maybe Hector is wrong. Isn’t that something any rational person should always consider anyway?

But the key aspect I want to focus on is the fact that Hector thinks he knows better. Linus is nailing the issue: Rust advocates think they know better. They know better than me. They know better than Christoph. They know better than old entrenched maintainers. They know better than anyone. They even know better than you (I’m assuming if you were a Rust advocate you probably stopped reading way back).

Note that I’m not saying all Rust advocates are like this, that would be prejudicial, a hasty generalization, and inaccurate. I’m just saying the vast majority do think they know better (based on my admittedly limited anecdotal sample).

That’s why the Rust worldview just isn’t compatible with the Linux project. The Linux way is from the bottom up: first a solution has to be proven to work, and then the leadership would accept it’s good. Rust advocates want it the other way around: they want Linus to decree Rust is good, so the decisions are carried from the top down, and everyone has to comply before it has been proven to work.

The Linux process has worked smoothly for decades, but progressives want change now.

The same way they cannot wait for societies to organically move away from standard pronouns (he/him, she/her), they would rather have a decree that makes it illegal to use the wrong pronouns, because once again they cannot be wrong about this or any issue, therefore any means are justified for the desired goal which is going to happen anyway (in their mind). The same way they cannot wait for developers to organically move away from the “master” branch, and they would rather have a decree from the Git project that “main” is the correct name for the default branch.

If you are right, it’s adequate to demand change now.

The key word that progressives seem to miss is the if.

I will have to conclude with “there is no perfect”. I don’t think there’s any phrase that could epitomize the C mindset as succinctly as this one. Yes, C is not perfect, but it works, and it has worked fine in the field for decades. The same cannot be said of Rust, no matter how hard Rust advocates believe they are right.

Personally I would take some “ugly” C code that is theoretically memory-unsafe, but has been honed for decades any day over a “beautiful” Rust code that is theoretically memory-safe, but was written last week.

But if you prefer Rust and you want to start a new codebase using it, I say go for it, it might actually be the best language for your particular needs. I don’t know, and I couldn’t know, because — unlike some people — I won’t pretend that I know better than you regarding what you need.

Here’s another attitude typical of the C mindset: live and let live. It would be better if Rust advocates didn’t lecture me or the Linux project about what we should want.