Does Rust belong in the Linux kernel?
Answering a question once answered by Drew DeVault.
Drew DeVault is an interesting guy to me. There must have been some kind of early life lunar impact for one of us that permanently set our courses apart, because upon seeing the logic and raw moral drive in his writing, I couldn’t be more in alignment. But when I look at the corpus he touts, and I saw his history behind it, I realised he was one of those Americans that moved to Europe to be closer to the ideology of bleeding hearts. I couldn’t share that kind of mindset if I tried, and I’d laugh in your face if you chalked what’s wrong with America up to capitalism. But that’s okay. We have a similar act on different sets is all.
I’m not writing this post to rag on him. I agree with him, and furthermore I took his post as a challenge to say something important regarding the titular question: Does God’s Chosen Programming Language (GCPL, otherwise known as RUST) belong in the Linux kernel?
Like Drew, I am a polemic about GCPL if I’ve decided on diplomacy for the day’s strategy. But on other days when I’m not feeling so kind, I consider myself God’s strongest soldier against the mind virus that is the Cargo Cult. My answer to this question is absolutely the fuck not, and that we even have to ask is an indictment of the field in itself. But before I get into that, I’d like to do what Drew did and answer a different question, since I, too, have a systems language that might fit the bill for ol’ Linus: Does C
* (read here) belong in the Linux kernel?
This is the perfect opportunity for me to bifurcate what seems like one question into two. To be honest, there are two contexts that programmers are increasingly talking about when they ask these kinds of sweeping yet seemingly technical questions. One context is the purely technical, which Drew was quite swift in addressing. The other context is political, which he waffled considerably more about. I’m going to answer both questions for C
* and then do the same over again for GCPL.
Verdict for C
*: yes and no
If you judge C
* purely based on how well it technically suits the problem domain of kernel space, well, wait no more. This really is the greatest innovation for programs that choke on recursion and find tuples hard to grasp since C itself was invented. Have you heard of flex structs? Or how about transmogrification for arbitrary character encodings? Attributes, bit-oriented struct semantics, code transclusion by symbols, and of course the pièce de résistance, law & order, are all things that will help any kernel project do its job that much better. Does C
* belong in the Linux kernel technically? Without a doubt.
* does not exist in a social vacuum, and neither does Linux or really any other project of note. There is this thing called clout, and if you’re paying attention you’ll notice that’s the exact thing Cargo Cultists are after with their “adoption” into Linux. Play a little devil’s advocate with a razor and ask yourself how much does their whole putsch really amount to? Linus has explicitly insisted that the kernel is not the receptive partner in this relationship. When you get down to it, they don’t have much to show for it besides a bunch of trumpeting emails and Gawker-esque fluff pieces, and the support in the driver code space, which isn’t the core kernel, and kind of depends on there being actual drivers implemented with to matter, which is a different problem they’re not even solving. I think Drew and I have seen this kind of dishonest tactic before.
I’ll say it up front: C
* does not belong in the Linux kernel politically. This is true without a doubt, and it’s because Linux has a political future that is entirely self-chartered at this point. The cargo cult’s gambit to steal clout from them is as cynical and corrupt as it is misguided and doomed for failure. Actually, like Linux, C
* also has a political future that is more dignified and, hopefully, self-chartered than this. C
* provides a host of great, new approaches in the vein of C that were never explored previously due to their dissimilarity to the preeminent fad of type theoretics and metaprogramming that has hijacked the very meaning of programming language development. It wouldn’t be useless for Linux, but I think adding C
* would be less of a groundbreaking era-defining event like the Cargo Cultists see their moment, and more like porting a C codebase to D using BetterC. Perhaps that’s a bit unfair to my language, but it doesn’t matter, because it’s not going to happen.
Now it’s your turn, Krabs
Technically speaking I don’t care to be as charitable as Drew was regarding the technical appropriateness of GCPL for kernel purposes. For what it’s worth I get the impression he avoided the question out of the sake of brevity and that it may detract from his main point, but I’m a lot fresher than he is with this, so I don’t mind to say: memory safety is a broken idea. It was broken at the drawing board, long before the first prototypal GCPL compiler was even ideated, and now it would be inconceivable for all of the people whose careers have been predicated on this mistaken notion to acknowledge it, so I don’t expect anyone but free agents to even attempt to take my side on this. I’m not trying to threaten your bread, but I am trying to avoid becoming complicit in it.
If you’re on the fence about this and have hopefully already seen me duke it out before with people about why the idea of memory safety doesn’t work, I’d like to invite you to read a certain cancelled huckster’s old blog post about what’s wrong with CS research. It really helps explain in a deep way how such misguided things come to pass here, and underscore how simultaneously antisocial and necessary what I’m saying about GCPL is for everyone’s sake. We’re wasting a lot of energy on this for naught. In conclusion, GCPL does not belong in the Linux kernel technically. Code is safe until it isn’t, at which point it’s as good as UB (shield your kittens), and in the mean time you’re spending an eternity fighting with a jailer to get your code to compile. I don’t know about you, but I’d rather have my scrotum stretched out over the front grill of my car before work every morning.
I’m harsher on the technical end of things than I am on the political because the former is just so much more inexcusable in my view given the circumstances and the kinds of people propagating this stuff. I know that you all know better about this. You are the people that get things done, and I know you’ve seen a GCPL program segfault at least once. We all have. Come on, man.
As for the political appropriateness of GCPL for Linux, it’s also going to be a resounding no (unsurprised, right?). Not only does the more benign reason that suffices for C
* also apply to GCPL, but one can find more insidious reasons in the nature of the putsch to get this language mainlined. The claims about memory safety are one starting point, but if that’s too difficult to grok, you can turn your attention to the kinds of reactions criticising GCPL invites. No technical degree required for identifying ideological fanaticism.
I’m not surprised Drew doesn’t want to rehash the dubiousness of memory safety – it must be absolutely exhausting threading the needle between a tiny reasonable minority of people who are trying to drill down to the truth of the matter, and random drugged-out demons who send you death threats for even questioning it. I’m not even a name and I still have my share of unhinged replies from cultists about my dissent for their pet programming language.
Insanities aside, I must echo Drew’s more mundane criticism of trendiness being the wrong measure of a language. I will take it a step further and say that it is abortive for anyone to have an allegiance to any programming language, as he says he does for his systems language. I think that’s what got us into this mess in the first place and spawned this unholy cargo cult. I don’t have any allegiance to C
*, and Drew shouldn’t have any allegiance to Hare, any more than Ken has allegiance to Go or C. Identitarianism is stupid and it’s especially so for programming languages. Can we stop this?
I didn’t create C
* to stake a claim in the New World for forty acres and a mule. I created it to help me solve problems I couldn’t practically solve before. The kinds of problems it solves are, to my knowledge, not adequately dealt with in this paradigm by any other language, so it satisfies a basic sanity test for a programming language: it helps say something that couldn’t be easily said before. Perl did this in 1987. I’ve done it again with C
*. As for what fame or fortune will be made out of this, I cannot tell you. For now I’m writing an assembler to help unify it with more concepts I’ve found useful in my exploratory informatics work, like modular memory semantics. This may work, but I can promise you the clout-chasing avenue and papering-over of misgivings with money and prose definitely doesn’t.