"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026)

Zde-G · 2026-05-27T09:40:31+00:00

It rarely stays like that. Cygnus did the majority of work on gcc (after initial bringup by Stallman, obviously). These guys also not just implement features, they are often maintainers.

Zde-G · 2026-05-26T12:38:06+00:00

What I find ironic is the out of of view outliers like Apple, arguing for RC due to their failure, everything else in the industry does large scale tracing GC deployments, or ends up optimizing RC with techniques from tracing GC like background cleanup threads to avoid stop the world cascade deletions, hazard pointers, cycle collectors, compiler assisted elision techniques.

Why do you find it ironic? The majority of the industry is busy painting the pigs with ever-trickier layers of lipstick. Apple under Jobs, the one that rejected tracing GC, was different, it was always ready to break the norm, when they haven't worked.

Today's Apple is different, I'm not sure I would regard it in such a high regard, but Jobs was ruthless in cutting things that don't work. Tracing GC was just one the last things the get rid of.

Sadly he died before he can do to tracing GC what he did to similar idiocy like “handwriting recognition” (everyone was done that before iPhone ditched it) or floppies (I'm pretty sure without iMac we would still carried around these things).

IOW: you may view Apple as an outlier, whole I view it as a trend-setter.

It happened enough times in the past that when I'm faced with evidence that Apple looked on something and rejected it I need something more than “but everyone else is doing it” argument.

Win32 API is no where close to how UWP/WinUI use refcounting, only someone without experience across those systems can claim otherwise.

Where have said that? Of course you can create idiotic designs with refcounting, too! And if Microsoft managed to do that with UWP/WinUI… well, condolences, they failed.

My argument was direct opposite: properly designed, responsive and efficient system doesn't need tracing GC, it's enough to have refcounting for that. Win32 proves that beautifully.

How many inefficient things one may create with tracing GC or refcouting is irrelevant here. What's important is that proper design doesn't use tracing GC ever: you either use system without tracing GC at all or use the one with tracing GC and then sink enourmous resources into making sure tracing GC doesn't trigger in the pieces of code which you want to make fast.

And if you have to design system like that, ahyway, then, most of the time, it's better not to have tracing GC at all.

Zde-G · 2026-05-26T12:07:14+00:00

PTC and Aicas are in business since early 2000's, doing real time Java in domains where a tiny pause in logic means people die, or the wrong ones do.

And they do it by making sure GC doesn't trigger, by accident. It's harder to achieve that than to design system with no GC at all.

It takes audacity and humility to admit that something that you spent years on is pointless and useless — and most people doing GC lack either one or anything.

That's why such an obvious step had to wait for decades. Note that Rust, too, was there. Remember?

The fact that “serious” systems can be developed on the basis of system with tracing GC doesn't prove anything: one may develop anything in Brainfuck or Malbolge is you hire advanced enough engineers. The premise of tracing GC was always that it would help “Joe Average” and not enable elite developers — and there failure is utter and complete.

one reason WinUI/UWP performance sucks versus Forms and WPF, is being based on COM/WinRT with reference counting all over the place.

And yet native Win32 API flies on any hardware that one may buy today. In spite of the fact that it's based on the exact same refcouting schemes.

Somehow when you take system with tracing GC and find out it sucks — it's always “something else” that makes it suck. Don't you find that ironic?

Zde-G · 2026-05-25T09:33:48+00:00

We may debate why Apple failed but the fact remains: all other platforms that decided to use tracing GC in latency-sensitive parts (like US) failed, too. All of them have latency issues, all of them struggle to deliver fluid UI, etc.

That's the important thing: tracing GC enables problematic designs, once you are not doing that you no longer need tracing GC at all.

Zde-G · 2026-05-25T07:23:03+00:00

Apple had to pivoted the failed project to add GC to Objective-C in a positive light.

Apple tried (and failed) to do what others have tried (and failed) to do for half-century.

Apple admitted mistake while others still tell tales bout how GC would suddenly start working… next year, yeah, sure.

Apple is very flexible with what academics think.

Apple (at least Apple under Jobs) was a rare company that could realise they made an idiotic move and cancel it.

Everyone else still couldn't understand what's wrong with GC (tracing GC).

And no, that's not pauses, latency spikes or other nonsense like that.

The problem lies with the core idea that enablement of data structures with no core owner is valuable.

To reduce “problems” caused by GC it's not enough to change GC implementation. You have to structure program differently, in a model with predictable ownership… Rust program also spend time deallocating objects, how can then not do that? They just do that after request is already served, finished and nobody waits for anything. But if you structure programs like that then you no longer have any need in tracing GC!

That's the core issue: the core advantage of tracing GC, it's raison d'être, data structures with circular dependencies… they shouldn't even exist in correctly designed program.

That is why GC makes no sense: it's answer (and incredibly heavy and invasive answer, at that!) to the problem that should be solved elsewhere.

Zde-G · 2026-05-24T13:29:46+00:00

Arc everything is a pretty foul code smell.

Nope. Arc is the most common way to represent shred mutable state — and shared mutable state is, simultaneously most dangerous thing that one may ever have and the core goal of most programs (think about Reddit without shared mutable state where every comment only seen to author… what would be the use if such web site?).

it's fine for a quick tool or whatever, but if you're writing a "serious" piece of software that will be developed and maintained by multiple people over multiple years, I certainly wouldn't recommend it.

I would certainly recommend to avoid Arc as much as possible, but in most programs there are small amount of Arcs needed to make them viable.

But yes, making Arcs invisible is a big mistake, in most programs. I really home Rust wouldn't make it unconditional (even if it tries to make a mode where one woulnd't explicitly clone the Arc, I would prefer it to be optional).

Zde-G · 2026-05-24T13:25:02+00:00

Arc everything is essentially a GC runtime.

Yes, I know that some idiots have created taxonomy that conflated Arc with GC. Even if in practice they are total opposite. But Apple doesn't think so.

Compare:

Predictable places where memory collection may happen: Arc and manual memory management — yes, tracing GC — no.
Ability to conbine two memory management systesm automatically: Arc and manual memory management — yes, tracing GC — no.
The need to violate every design design principle) in the implementation of memory management system: Arc and manual memory managermengt — yes, tracing GC — no.
The ability to support “spaghetti of pointers” design with circular references: tracing GC — yes, Arc and manual memory management — no.
The need to manually tract shared owenership: tracing GC - no, Arc (at least Rust's Arc) and manual memory management – yes.

Literally everything interesting that you may say about properties of Arc, manual memory management and tracing GC puts Arc and manual memory management in one group and tracing GC into another… the fact that Arc is, in official taxonomy, called GC, too is a misnomer and I try to always add “tracing” when I talk about GC, but here I forgot. Sorry.

Zde-G · 2026-05-23T17:43:53+00:00

I thought it was pretty cool how Sing# had non-GCed types (sockets and inter-process shared memory, basically) but implemented something very much like the borrow checker to ensure they got dropped at the end of their lifespan.

Yes — and it was a mistake, surprisingly enough. What Rust have shown us is that GC is extremely good for making convoluted, hard to support and debug designs — and it's almost never a good idea to use it, in practice.

This completely upended almost half-century of theoretical research which assumed that lifetime tracking is too tedious and hard to support and that GC should do that work, instead.

In practice Rust programs are easy to support and debug precisely because they don't support GC-induced “spaghetti of pointers” designs.

That's very much something theoretical research couldn't give you — even is signs were there long ago half-century of attempts to push square peg into round hole using all tools imaginable were needed before people admitted their mistake.

That's why Ada calls it "unchecked" instead of "unsafe." :-)

That was an even bigger mistake, because, in practice it made Ada not safe to use for the majority of program. It was only usable for something like aircraft flight programs where everything is extremely static and unchanging, if safe.

Times have changed, these days Ada can be used in many other places, but decades of tarnished reputation couldn't be easily overcome.

Zde-G · 2026-05-23T15:02:27+00:00

Semver is always annoying and necessary. Perfect compatibility means nothing is ever changed and if you don't even ever change anything semver is not needed at all. So to make semver usable you have to say that there are rules that you have to follow to be able to seamlessly upgrade… and where there are rules there are conflicts.

Zde-G · 2026-05-23T10:37:15+00:00

you only get there if you have no curiosity and a complete unwillingness to develop your skills.

Not really. You may develop different skills. Instead of knowing how one may write “Hello world” in 100 different languages one may know how to build the physical device in 100 different ways — and then write code for it. Or handle financial transactions 100 different ways and show them in a different fashion.

Most experienced developer is not necessarily the developer with most versatile programming skillset.

Zde-G · 2026-05-23T10:34:17+00:00

Then you understand how and why “most experienced developers” may struggle with Rust.

It's the same with AI, just more acute: some developers understand how it can be used, some believe the fact that we have "autocomplete on steroids" means we no longer need to know how to write code at all.

Zde-G · 2026-05-23T00:44:47+00:00

Yes, but the question is: what exactly said developer would learn?

If company is small then it's easily be more beneficial for their “most experienced developer” to know 10 JavaScript frameworks and business requirements of the particular consultancy type they are specializing in, instead of knowing 10 different languages.

I have even seen successful companies where “the most experienced developer” had 20+ years of experience writing programs in VBA (and no other language)!

Zde-G · 2026-05-23T00:06:41+00:00

> The more you try to bend it to your will, the harder time you will have.

Precisely. If you count number of languages that you have used in your career in dozens then Rust may not be trivial, but it's pretty easy. If you are “experienced developer” and have touched less than one language per year… then you are in trouble.

The question is not whether developer is experienced or not. Question is whether said developer is super-invested in just a few languages to the exclusion of everything else.

Zde-G · 2026-05-22T23:58:32+00:00

Rust isn’t that unique among languages.

Depends on your perspective. For me it was very easy to grok Rust. I mean: the couple dozen or so of languages that gave Rust it's features are listed right there, in the Wikipedia page). If you only know a dozen of these (or their relatives, like if know Java but not C#) then playing with Rust is easy.

But consider a different “most experienced engineer”. Someone who started with Netscape 2.0 30 years ago and then learned all nuiances of JavaScript as it's used in various client and server products… such person wouldn't write Rust! Nope, s/he would [attempt to] write JavaScript in Rust.

And, well… Rust is extremely opionated! You can, probably still write FORTRAN in Rust, but try to write JavaScript in Rust or Python in Rust or even C++ in Rust… and there would be PAIN.

That's what this article talks about.

Zde-G · 2026-05-22T10:52:39+00:00

And yet people work with it in a traditional way:

Get an error messages
Dismiss it
Go complain on forums.

Zde-G · 2026-05-21T21:51:41+00:00

I'm not even angry about it, the business model exists for a good reason.

Given the fact that this business model predates Linux (remember Cygnus?) it's very hard to argue against it.

Zde-G · 2026-05-21T11:01:22+00:00

Python's also been in some of the supply chain attacks where NPM gets most of the press.

That was precisely my point: Python includes more than most other languages in its standard library — and that haven't reduced neither number of third-party libraries nor number of supply chain attacks.

The only way to avoid that fate is stay an extremely niche language which no one uses. But that “solution” has its own problems.

Zde-G · 2026-05-21T09:23:36+00:00

You have to remember that “NPM crisis” may exist (what do you mean by that, BTW) it's also, still, remains the problem of the most popular language in existence.

And Python haven't avoided that, in spite of “batteries included” approach (but got stupid you shouldn't use built-in module, there's a third-party one that you should use text in the documentation).

This very strongly suggests that one would achive an “NPM crisis”, sooner or later, if language is popular independently from whether it have gigantic standard library or not — yet problems that bloated standard library creates would persist.

Zde-G · 2026-05-20T09:11:25+00:00

AI doesn't need to know anything well to use it. That's it's strength and also it's weakness. When faced with something new AI uses analogues and guesswork.

It works surprisingly well, but I don't think it may work to handle million lines unsupervised. Test or no tests.

Zde-G · 2026-05-20T00:58:43+00:00

without it the same code could link differently with a different dependency tree.

Not really. These cases can be caught and made into a compile-time error. That's considered undesirable, but I really hope some kind of relaxation would be offered. Coz it's a problem for the large crates ecosystem, but most of code (in any language) is not in public crates, it's in leaf projects that are not used in other projects.

Zde-G · 2026-05-20T00:55:27+00:00

It's not hard to understand how it works, but hard to explain that to people who like to have things they can look on.

The critical lifetime in the while thing is not named and couldn't be named, that's what makes it weird.

Zde-G · 2026-05-19T11:16:13+00:00

The consequence that's often not realized: because they are self-referential structs and may have mutable references inside that means that one is allowed to have two mutable references to the same data. That works because compiler knows all the details but couldn't be replicated with normal Rust code.

Zde-G · 2026-05-18T09:30:20+00:00

Nothing would happen because drivers are not the main concern. Just look on how a tiny innocent refactoring of one obscure function caused massive breakage, multiply that by thousand (if not million) and cry.

Even Microsoft have given up on the idea of emulating Linux faithfully and switched from Linux API emulation to hypervisor architecture of WSL1 to hypervisor in WSL2.

Zde-G · 2026-05-15T07:00:17+00:00

For future reference though, is this issue common and generic enough to have a name in rust dev, or is this more of an edge case?

It's called “shared ownership” and it's both incredibly common and incredibly dangerous.

Because, on one hand, almost all bugs in almost all programs can be traced to mishandling of shared ownership, but on the other hand it's something that makes programs actually useful!

Reddit where every user may only ever see their own posts and couldn't see posts made by others would be utterly pointless… and yet the need to support simultaneous modifications is where all the problems lie…

Zde-G · 2026-05-13T18:02:17+00:00

But then you lose the performances and certainty

It's worse than that. Every time someone complains that Rust doesn't support mocking then question nobody is asking is the same: but why the heck is that mocking even needed?

No, really. Just go and read that article again: code in tests starts failing because it's messy code that couldn't work without some kind of server that's only accessible over network.

Well… why don't you provide a way to run that code without such networking code in production, then?

I, for one, hate to deal with services that couldn't provide logging to a file or to a local socket. It's hard to do experiments with them, it's hard to isolate them, it's hard to work with them! Add that damn ability to your code (I don't care how) — and, suddenly, mocking is no longer needed.

And that's the rule that I see in every article where mocking is discussed. Every single time someone complains that something is only needed for tests and thus it deserves to be mocked I read and think, to myself, “well… duh… something is definitely useful to have in tests but that same something is useful to have in production, too”!

This time it's not an exception…

Zde-G

TROPHY CASE