Asahi Linux lead developer Hector Martin resigns from Linux kernel

>Human validation is insufficient and error prone,

Basically, if you assume thats impossible for humans to be correct, or that its impossible to write correct memory safe C code, you start down the path that leads to things like Java, Haskell, and now Rust. And then when nobody takes you seriously, you wonder why - well, its because you are telling people who know how to write correct and memory safe C code that we are insufficient and error prone

>Kernel modules aren't that special.

By definition, they interface with the core kernel code. They are not core kernel code

Because it forces the developer to think about what is being written at every step of the way, instead of relying on language features that are by far not complete in terms of providing memory safety.

Naive take would be that it adds abstraction that you need to keep checked, in addition to the kernel code itself. Not making a value statement at all on the level of impact that actually has in practice.

Rust with manual memory management is just more cumbersome than C

> Isn't the current Linux already Linus + communities + companies?

Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.

The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.

> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.

I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.

This is already how projects like Android work.

I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original.

(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)

Yes, it technically does (kernel modules), but the difference between Linux and NT is that Microsoft guarantees (as much as possible) that its ABIs are stable whereas Linux explicitly does not preserve backwards compatibility in the kernel (only the userspace is the stable interface).

It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.

Yes, it can load drivers dynamically.

There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.

A driver written for one release of Linux may not work with the next release as the API changes.

To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).

They did: https://github.com/aws/aws-lc / https://github.com/google/boringssl

(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)

Rust aside, it uses a microkernel, multiserver architecture.

And, of course, drivers run in userspace and interact with the system through a clearly defined API.

Other systems like this include Robigalia, Lions OS and Genode.

They would likely quickly overtake Linux if they got 1% of the resources Linux receives.

Do the Rust drivers provide significant benefits over C equivalents (or over typical C drivers), enough to make it worth switching?

Rust may have to really prove itself with results. And why shouldn't it?

You’re right - add insufficient leadership to the list as well.

IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).

The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.

Apparently GregH(?) had already stepped in earlier to resolve the issue before it blew up again. But I’ve not been following it closely.

>Both were wrong, but only one was corrected.

People are wrong in LKML often.

This time, somebody was wrong in a much worse way than usual.

Thanks!

this seems very inefficient and the opposite of what I assumed. repeated requests take up time on both sides and are not a very good measure of how important something is.

why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?

Quite the opposite. If you “pester” for something, they’ll explicitly reject it.

Then you get stories like Greg in the linked mail thread, who emailed to check after not hearing anything and got told that now he'd been annoying and it would never be done.

Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.

In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI.

In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.

I haven't touched Gecko in a decade, but your second paragraph sounds like my experience. My best record was something like a single character bug fix taking months (might have been years?). Yes, the review flag was set to the right person.

I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…

I can understand this mindset, but I also think this is how communities die. They go to great lengths to avoid inconveniencing existing members while neglecting to welcome new ones. In the short term, the better choice is always to favor the existing contributors right up until they start dropping out and there's no one left to replace them.

Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.

I really like the way sourcehut integrates mailing list patches with a good UI. I’d like to see that become more common in some of these “classic” open source projects.

That optimization includes things like email filters and email client customization that is individualized to longtime contributors, not to mention that it is just what Linus and others are used to. And the long time contributors have had years, or decades to incrementally set up their tools, and become familiar with the workflow. The problem is that new contributors and maintainers don't have that, and learning the workflow, and setting up tools so that the email based workflow is manageable is daunting and takes a lot of time.

I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.

That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.

But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.

> [..] a workflow they have been optimizing for decades.

it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?

> a workflow they have been optimizing for decades

obligatory reminder about breaking someone's workflow https://xkcd.com/1172/

That sounds about right - the medium is the message. If you can't stand the clunky-but-working, decades-old, patch process, you probably won't stand the clunky-but-working decades-old code.

I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy

I've contributed to a couple of projects that use email based workflows. I can customize my environment, but it takes a lot of time, and I would rather do something else than figure out how to filter the firehose of a mailing list to the few emails I actually care about, or learn how to use a new email client that is slightly better and handling patches.

The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.

Can't or won't? Surely what you just read would make you reconsider?

The short version is:

- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list

- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily

- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)

They do, but they have a stated goal of maximizing contribution. Linux does not, right? I'm asking.

Different Wikipedia communities have different governance policies. In the math wikis there's generally a rule that small fixes are not allowed. This stops people from arguing whether slightly better explained sentences are the right edits.

"To interpret it differently requires bending the mind."

Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.

I'll bite and play devils advocate here - both of those are not a solution to his problem. Ultimately he's the maintainer and he gets the emails if X driver is broken, so because of that he doesn't want to rely on another group to maintain the 'Rust half' of his part of the code. It's also a system that works until it doesn't, the biggest rule of the kernel is no breaking userspace - at some point in the future it won't matter if it's his C changes breaking the Rust drivers, it's still his changes that have to be rolled back if the Rust code isn't updated.

And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.

He meant to say "the Rust code will spread everywhere [like cancer]".

I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).

Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.

As I argued a few days ago: part of "being nice" is accepting that people aren't perfect and dealing with that – https://news.ycombinator.com/item?id=42940591

He wasnt talking about Rust specifically, he was referring to codebases in any other language.

He said: “ And I also do not want another maintainer. 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).”

Mixing codebases in the Linux core.

I think the conversation is more about people equating R4L as validation for rust or even themselves.

Or worse: Linux is so widespread and managed to practically kill most Unix alternatives, that progress in OS development is slowed down globally. I would strongly prefer Linux being an OS with a lot of progress to stagnation and possible no alternative in the next decades.

You have to be pretty clueless not to understand that Martin's is wrong here, he, and the rest of Rust bozos he clicks with should have been kicked out of the Kernel the minute they started with their social media drama... of course, drama and rust are just bound to be hand in hand.

I think the response from Dr Greg to Linus, https://lore.kernel.org/rust-for-linux/20250207121638.GA7356... adds some interesting insights.

There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?

These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.

https://archive.is/rESxe

This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.

I think this is an important data point, too:

Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...

Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.

Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

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

That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.

> Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later.

That sounds very cult-like, doesn't it?

When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared.

Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.

It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.

[flagged]

I feel the exact same. Marcan has done amazing work, and his random blog entries etc have saved me hours of debugging time in the past. But jeez, it is really painful to see him say absolute nonsense like "If shaming on social media does not work, then tell me what does, because I'm out of ideas." - he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.

I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.

Like others have mentioned it was really the hypocrisy of this guy that made me side against him, not so much whether he was right or wrong.

He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.

A serious case of the pot calling the kettle black.

[flagged]

> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.

If something is not clear, ask him to elaborate.

But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.

It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.

Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that

Where? Because "keep the wrappers in your code" and "do that in your driver so that you have to do it instead of spreading this" doesn't sound like that.

Are you referring to Hellwig saying, "No rust code in kernel/dma, please."? I took that to mean just dma.

Just curious. Why can't the wrapper be an independent library outside of the DMA infrastructure? It can still be used by all rust drivers.

I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.

I am aware. Doesn't mean it's not an option, or even a bad idea. Or maybe there is a third option; I don't know.

By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.

And there is no issue with that. What's this pervasive need to spread Rust to every part of the software space. It's just becoming a little too pushy and desperate

What an absolutely awful statement about one of the most successful community projects ever. Direction usually comes from the community and the maintainers just steer it. Little in the kernel comes from maintainers saying "let's do X" and community members implementing it

Perhaps you could fork the kernel and start a better community?

All of those inventions were invented at least a couple years before the Apollo program.

[flagged]

Some of Linus's past messages came across as needlessly aggressive and insulting. There really was no practical reason for that and just served to alienate contributors, and it came across as unprofessional.

You can be a strong, opinionated leader and still be kind (or at least neutral) to the people you're working with.

A good leader is someone who can deliver hard messages while still keeping your team inspired. It doesn't do any good if the people working under you feel like trash.

It's the difference between telling a contributor "you're an f**ing idiot" vs "this code isn't up to standards, try again". Same message, but completely different impact on your team.

Bad faith arguments like this don't really belong on HN. Please represent the substance of your argument accurately rather than debating this inaccurate strawman argument.

You seem to be implying that he had nothing to apologise for, and that abusive behavior is an acceptable part of strong leadership.

It’s sad that this even needs to be called out.

Yep, that happened. "Forced to apologize" essentially describes it.

A quick sweep through recent messages in LKML shows that there's a healthy return to form for him, maybe with less curse words, but as succinct and impactful as it should be nonetheless.

There is an LWN summary of it out already:

https://news.ycombinator.com/item?id=42968782

I love Linux and have no preference to either C or Rust, but locking Linux in to a programming language that was designed in the relatively early stages of computing will lead to Linux dying in the long term.

There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.

I agree. If it wasn't for the memory safety meme this would have never been considered.

Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.

Not "religious" (even though I've used the word "zealot" right here) but rather political or social.

those are still technical merits/non-merits, albeit on the project management level.

The rust doesn't write itself.

Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.

> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers

And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.

> that's a strategy decision that should not be up to any subsystem maintainer

So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?

> I don't believe that was what the rust guys thought they'd be signing up for

It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.

> that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers.

And that's a perfectly resonable position.

> Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".

Which is a valid viewpoint. Let's not pretend that's not a technical argument.

Having different technical views from yours isn't a crime, legally or morally.

> And Linus has already approved Rust in the Linux kernel, so what's the problem?

As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.

https://docs.kernel.org/rust/index.html

https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...

Just read the email.

A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.

I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.

> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things.

Both sides of the argument are kernel developers here, though.

The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists.

Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.

To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side.

Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).

Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).

The issue is it creates a downstream dependency on his code, even if it is 100% separate and separately maintained.

Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.

So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.

Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).

If that is true, why he was the one that was asked to review/ or why his opinion even matters here? The must be some sort of correlation to his code or this does not make sense at all..

It's just in his area where he has the power to say no, and it's important enough to be a big impediment to the whole project.

is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?

Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.

Why would a Rust for Linux fork want to stay up-to-date with all the latest commits that are in C?

If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.

I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man.

That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.

https://blog.ffwll.ch/about/

> Currently I work at Intel’s Linux Cloud SE group, mostly creating havoc in kernel driver’s given my more than a decade of work in the graphics subsystem. I’m also co-maintaining the graphics subsystem. I also have been drm/i915 kernel maintainer for a few years, but handed that all off to a great new team.

I like to not assume the worst, more so on HN, but I do run into a lot of situations elsewhere on the internet where "virtue signaling" just means "someone said something I don't like".

But generally I do like to wait to understand specifically what someone means before assuming.

so how should it be called, in good faith?

[dead]

> Maybe closed source is better.

I've had similar pissing matches in closed source development, instigated by me and not...

Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.

But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.

> Seeing what it has become though… Maybe closed source is better.

You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.

This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.

And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.

> Maybe closed source is better.

At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:

Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.

> Seeing what it has become though...

Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.

With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.

> Maybe closed source is better.

It's the same and worse over there, the drama just isn't public.

> "Maybe closed source is better."

I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.

I hate to mention this but closed source appears to involve humans too. I was disappointed when I discovered this as well.

FOSS devs put a lot of time in what they do and they are understandably attached to whether what they do is good/successful, at least in the same proportion the general population is (but arguably more due to how much dedication goes into FOSS, kind of by construction)

>Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?

There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especially if that was a choice and not something imposed on it. It is choosing one thing about the other that leads to narratives about why you have done a certain thing, something that is usually connected to your self-image.

There are a number of cognitive trends that converge to create this behavior. This assignment effect appears when you feel that the things you have are superior to things you don't have. Another bias is the fallacy of irrecoverable costs. This happens when you spend time or money on something you don't want to have or don't want to do, but you can't avoid. For example, imagine that you spent time studying Rust. You will be "hooked" on the idea that given the time spent in this, it is better to defend the language, even if you imagine that it is not for all things.

To combat post-decisional dissonance, the feeling that you committed to one option when the other option could have been better, you strive to feel justified as to what you selected to reduce the anxiety created when questioning himself. All this forms a gigantic group of neurological associations, emotions, details of self-image and trends around the things you have.

> Is your theory that rust makes people dramatic? Or that dramatic people like rust?

Both, really. As a language that was designed from the ground up to be a replacement for C and C++ (thus implying that it's superior to these established languages), it positions itself as inherently "dramatic" and anti-establishment.

This obviously attracts these political activist types who love to insist that their way of thinking is the way forward, that everyone else was simply doing it wrong before they came along, and that anyone who questions their beliefs is an obvious enemy of progress who should be silenced at all costs. It's a cult, basically.

I think the second one is more likely. People choose languages and ecosystems which fit their way of thinking so naturally, the ecosystem shifts to that direction. This is a self-reinforcing loop :) (one can naturally see this in many languages when the language advocates say "you are just holding it wrong...")

I'm inclined towards the second explanation. But whatever the case may be, there really is an unusually high amount of drama in the Rust community. Maybe Rust just attracts really passionate nerds with a lack of social skills, IDK. But there's something going on there.

Probably just Berkson's paradox https://en.wikipedia.org/wiki/Berkson%27s_paradox

I would argue the second.

I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.

Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.

I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.

1. https://en.wikipedia.org/wiki/Trump_(card_games)

that’s exactly my question. why can’t he depend on C API and just consider it is memory safe and all.

> whether he's just lying, or both things are true and he just deleted his account after it was suspended

This is obviously just a Mastodon bug (backend treats suspension and deletion as the same thing, for example). I'm not sure why one would entertain the idea of marcan making up a lie about being suspended from an instance he's an admin of.

Actually… I'm really not a fan of how Mastodon handles account deletion. I've interacted with him there about a week ago, and all of his posts are now missing from those threads. I guess it makes sense from a "be able to change your ways and not be stuck with ancient bad things you did" perspective, and there's a right to deletion/"be forgotten" in some legal frameworks, but this hinders necessary community processes. At least the LKML mails are permanent…

I would've liked to link a post or two of his to show just how little flexibility and tolerance there was from his end regarding his social interactions, even when being questioned about them in an outside context and in a reasonably neutral manner. Ohwell…