9 ms·

RAII and the Rust/Linux Drama

98 points by _tbl6 2y ago

neonsunset 2y ago
Except Arenas are well expressible in Rust. What's more, the fact that there are lifetime constraints allows to have both safe and idiomatic abstractions for them.
raggi 2y ago
This article implies that batch allocations are some kind of panacea and that raii has no place there. Neither of these implications have any case made for them, just links to other publications that do the same. It also alludes to downsides but fails to define them, and also misses documenting any downsides associated with alternatives. Despite deep familiarity with the space and understanding of both sides, I can’t really see it saying anything much at all in fact
- raggi 2y ago
  There’s a one-sentence implied claim in here that raii is the reason for c++ rejection and rejection of c++ implies rejection of raii. The author is clearly unaware of the recent cleanup attribute infrastructure submitted on the c side of the kernel: https://github.com/torvalds/linux/blob/master/include/linux/cleanup.h https://github.com/torvalds/linux/blob/master/include/linux/... Zig is a fun and interesting language in its own right, there’s really no need for this post-truth era style propaganda. Just focus on your own work
- mathw 2y ago
  Basically the same conclusion I came to, I was hoping the article would really make a point at some stage but it just fizzled out without really asserting anything with any supporting evidence. I particularly didn't enjoy how it completely failed to take into account the well-established practice of using RAII alongside arena allocation in C++...
sunshowers 2y ago
> The fact that Rust developers who are interfacing with the Linux project seem completely unaware of the downsides of RAII, reminds me of when the US ambassador to Denmark thought that their collaborators biked to work because they were too poor to own a car. I would imagine kernel developers working with Rust are quite aware of the downsides of RAII when it comes to large synchronous drops, and aware of arena allocation patterns. They are also likely aware of both arenas that run destructors on drop, and arenas that don't, and the relative merits of each. They are also likely aware of arenas that you can garbage collect over time, as enabled via generational index patterns. The good news is that if profiling shows this to be a bottleneck, it is relatively easy to safely switch code that does allocations to using an arena instead (you'd have to add a lifetime parameter to everything tied to the arena). RAII remains a great way to solve many real problems in systems programming, and banning tools which enable it on the off chance that you'd run into performance issues with synchronous drops, without any data to back it up, doesn't seem wise.
- perching_aix 2y ago
  The author's line of thought seems to be concerned with the social aspect of RAII in my reading though. Like how you can write memory-safe C if you're a "good C programmer" (meaning most people evidently won't), these considerations for RAII might be subtle enough that it justifies banning its use altogether (like using memory unsafe constructions is in safe Rust).
  - sunshowers 2y ago
    A sibling comment [1] points out that the kernel recently gained some RAII-like functionality. The typical alternative to RAII-based error handling in C tends to be goto statements. I'm sure those of us who have written C are used to writing goto statements in inverse order for their error handling -- and we've also made mistakes with them especially when there's a lot of branching paths (or at least I have). In comparison to that I personally appreciate RAII quite a lot. Even with arena allocation, it may make sense to have a struct be composed of some memory that's borrowed from the arena and some that's owned by the struct. That works exactly as you'd expect in Rust. [1] https://news.ycombinator.com/item?id=42291921 https://news.ycombinator.com/item?id=42291921
diath 2y ago
I've always wondered why not just fork Linux and add Rust there then keep it in sync with mainline and maintain it long time to demonstrate that it's a viable strategy and there's enough volunteers willing to actually spend their time instead of turning the Rust part of the kernel into abandonware when there's so few developers available, before trying to get it supported upstream?
- 0cf8612b2e1e 2y ago
  Just fork one of the largest open source projects in the world? Linux has many contributors who are paid full time to improve the project. Something that is impossible to match in a sideshow project.
  - diath 2y ago
    Exactly my point, if that cannot be done as a third party project, then shoehorning Rust into Linux and expecting unpaid third party volunteers to actually maintain it makes no sense. Unless a big corp steps up to fund such efforts, it's pointless.
    - lesuorac 2y ago
      It's Linus's project. He wants to allow Rust. If you don't then you fork it into your own project lol ...
    - sunshowers 2y ago
      Linus has already decided to accept Rust! A fork would simply not be practical. Disagree and commit.
      - tkahf 2y ago
        How much of that is the opinion of the corporate masters who fund the Linux Foundation? Why Rust and not Ada for example? Rust is heavily promoted by web developers who call the shots these days because they bring in the advertising money. I find it hard to believe that Rust is the end of all other languages, especially given its ugly syntax.
wk_end 2y ago
The author of this is the VP of Community for Zig; his only professional experience, according to LinkedIn, is in similar advocacy roles. It's an incredibly bad look for the Zig community then, in my opinion, for him - somewhat sarcastically and disrespectfully ("oh no!", "I already have to waste way too much time for other slow software to load") - trying to school Asahi Lina on "writing performance-oriented software" when she's one of the most impressive software engineers in the public eye right now. This is just a FUD-y hit piece on RAII. It, frankly, smacks of Dunning Kruger (I know, not statistically a real thing, but rhetorically useful): a writer way beyond his depth hears someone praise RAII, and out of ignorance and professional obligations launches an attack by linking some canned "RAII Bad" sources, not realizing the person they're attacking knows vastly more about...well, basically everything, than they do.
- sunshowers 2y ago
  Oh, I didn't realize that. I guess I should add a disclaimer then: a mean and condescending tweet from him caused me to withdraw my sponsorship of Zig a couple of years ago.
  - deleted 2y ago
    [deleted]
- pseudony 2y ago
  This is not his best post, granted (there are some good ones). That said, I think this is a very uncharitable read and resorting to ad hominom (he's not a real dev!) is uncalled for. If you think the argument is wrong -say so. Refute it on its own merits. It gets no better or worse from it being said by him. That also goes for Asahi lina - I find it so incredibly tiring when people's hero-worshipping of this admittedly great developer extends to thinking they are simply right about everything. Carmack is a great dev, he likes his C and C++. Alexis King (Lexi Lambda) used to be a top lisper (likely still is), now a great haskeller. Rich Hickey and so on and so on. Point is - how do ypu reconcile the fact that these people hold wildly different ideas on what makes good programming and programning languages, some of them even changing opinions over their lifetimes. Will you create a programmer godhood pantheon and claim Asahi Lina is the smartest person ever or write it off as "systems programming must be Rust"? I am curious. Anyway, not aimed at singling you out, but the appeal to authority (Lina) as some way of saying " this is right, everyone else are wrong" is shoddy arguing.
MuffinFlavored 2y ago
> RAII Resource acquisition is initialization
- Ericson2314 2y ago
  The name is terrible, all the more so because we are talking about deacquisition and deinitialization most of the time.
  - pclmulqdq 2y ago
    RAII is really all about the deconstructors, not the constructors.
  - justincredible 2y ago
    [dead]
matt3210 2y ago
Imagine this: we have a group of friends and we’re having a good time. We all speak English. One or two guys invite some people who are always speaking in Klingon. They invite more and now a large amount of the group wants to have equal support in d&d and other activities for Klingon. They insist it’s a better language when it’s only just a different language, not better or worse. The English speakers are trying to stop the Klingon speakers from changing their group to something new that they don’t like (and not provably better). Rust is Klingon. C is working fine and is the language everyone is already familiar with. If Rust was actually better, it would flow into the ground organically. Being technically more memory safe doesn’t make people like it more. Proper tooling with C can prevent memory issues, taking away the main argument for rust. In the end we don’t need any more of a reason to stop rust other than “we don’t like rust”.
- perching_aix 2y ago
  > If Rust was actually better, it would flow into the ground organically. What would Rust flowing into the Linux kernel organically look like in your opinion? On a similar note, I work in a non-English speaking country, but have developed a real bad habit of sticking to English when it comes to technical discussions (work or non-work). Mind you, this is an international company we work at, proficiency in English is expected (and often lackluster). My colleagues don't appreciate this, and will poke fun at it from time to time. They're convinced I'm being obnoxious on purpose, despite me just spending 90% of my day interacting with English in English. It is only natural then that I keep thinking about things in English. What you'll discover is that these colleagues of mine have two things in common: they're not anywhere nearly as immersed and proficient in English as I am despite working here for a decade, and that they're a bit of an old-timer jackass types. This was not metaphor.
  - matt3210 2y ago
    I don’t know what it looks like, but it’s definitely not forcing people to accept it. Rust right now just isn’t in a form that some (I personally think most) people can accept. Maybe it’s just that it’s so not-c-like. … given your language examples, maybe the main issue is just that rust is just so different. I personally find the rust language to be non intuitive… but what’s intuitive for me is heavily informed by c/c++ or python
jitl 2y ago
This is a very silly straw man. RAII style is a syntax feature that doesn’t imply a specific semantics for how big the “resource” is, or how it’s allocated or freed. The only difference in Rust versus Zig is that Rust calls the de-allocator automatically and invisibly, and Zig requires allocation use an allocator parameter and an explicit call to free. Neither forces you to allocate batches at a time, nor do they prevent batching or use of arenas. To me it seems just as easy to allocate MyStruct[100] in either language.
- csb6 2y ago
  Exactly - people seem to assume that RAII means having to heap allocate each object individually and then having to deallocate each object individually when done. Clearly that is not true and the allocation patterns are orthogonal to whether RAII is used. RAII is also useful for non-memory related tasks like unlocking mutexes once the lock is no longer needed, which is just plainly useful in any language that allows functions to have multiple exit points.
  - jitl 2y ago
    I would prefer explicit linear types for locks, I find following Rust code using locks is very confusing - like an compiler-enforced call to `defer drop(lock)` to make it clear how it works. But I'm a noob at Rust.
  - ozgrakkurt 2y ago
    A lot of concepts don’t directly mean you have to write bad code but they push you in that direction. Fact is, arena allocation or any other kind of custom allocation is pretty much non-existent in rust. Hopefully it will be implemented soon but I’m not sure if it is feasible because of lifetimes
    - whytevuhuni 2y ago
      How so? I've been using arena allocation with the bumpalo crate [1] with great success. I also wrote my own arena allocator for a WASM project, and also wrapped Nginx's memory pool via safe APIs. I'm not going to claim that writing one correctly is easy... much like writing any low-level allocators, you have to deal with layout, drop order, unsafe cells, etc. But using them? The lifetimes work great with them. And the allocator trait [2], once released, will make it so std collection types can be used as well. [1] https://docs.rs/bumpalo https://docs.rs/bumpalo [2] https://doc.rust-lang.org/std/alloc/trait.Allocator.html https://doc.rust-lang.org/std/alloc/trait.Allocator.html
actuallyalys 2y ago
The confusing part of this article is the argument that the kernel maintainers are strongly against RAII. While I guess it’s possible Asahi Lina is unaware of this or is stubbornly including it anyway because she believes it’s such a large benefit, it seems more likely that it isn’t actually the dealbreaker. In fairness, I’m hardly an expert on C++, Rust, or kernel development, so it’s possible that I’m missing something.
- MuffinFlavored 2y ago
  > it seems more likely that it isn’t actually the dealbreaker. What is the dealbreaker then?
  - actuallyalys 2y ago
    I’m not sure. One point I agree with the author is that it’s a complicated situation likely involving both social and technical factors.
  - sunshowers 2y ago
    I think C++ drags a lot of bad stuff in with the good, and it is reasonable to be skeptical of it. For example, I think it was bordering on malpractice for lambdas to ship without anything resembling a borrow checker in place. With lambdas that borrow from the stack, introducing memory safety bugs is shockingly trivial. Even if your codebase bans lambdas in C++, it's quite reasonable to not fully trust the teams which made the decision to ship them.
quotemstr 2y ago
This is a "Structure of Scientific Revolutions" scenario: https://press.uchicago.edu/ucp/books/book/chicago/S/bo13179781.html https://press.uchicago.edu/ucp/books/book/chicago/S/bo131797... In any field, be it engineering or the sciences, accomplished and intelligent practitioners find themselves resisting new technology for reasons that are ultimately inscrutable and personal --- for example, fear of the unknown or fear of new technology devaluing their in the old. Because these practitioners are experienced and intelligent, they're able to construct elaborate plausible-sounding technical arguments against the new technologies. But since they're starting with the opposition and working backwards to a rationale, what these practitioners do when they argue against the new technology isn't so much science as apologetics. Apologies can be frustrating because, superficially, they resemble earnest argumentation --- but because, in apologetics, the authors starts with a conclusion and works backwards to an argument, an apology contains insidious logical traps that are difficult to detect and disarm, especially when the new technology (as all new technologies do) contain genuine gaps and flaws. It's because of this dynamic that many fields advance "one retirement at a time". We should all make a conscious effort, when evaluating new technology, to distinguish earnest technical criticisms from justifications for feeling averse to change --- and consciously suppress the latter.
- alextingle 2y ago
  Are you saying that RAII is "new technology"??
  - quotemstr 2y ago
    If you're a lifelong ANSI C programmer, RAII is new and scary.
asveikau 2y ago
RAII is all about making the compiler do what the "disciplined" C code is already doing manually. As mentioned elsewhere in this thread, a common C coding style and idiom is to goto to the end of your scope, where all the free calls go. The resulting behavior is pretty close to RAII. The argument in favor of RAII is that it's a lot less error prone to let the compiler write that part for you. A fine goal of course, but I feel like this post is overstating it or perhaps conflating it with something else (eg. The aside about trying to convince the GPU API maintainer that the issues they hit are also affecting drivers written in C may have little or nothing to do with rust or RAII)
- flohofwoe 2y ago
  The problem is that since cleanup with RAII is so 'simple', you tend to forget about it, and then you're suddenly in a situation where destroying a single object results in a cascade of thousands of other tiny destructions. So now you actually need to think about a proper memory management strategy (even though you have automatic memory management) and will eventually arrive at arenas as the solution, and once you're there, suddenly RAII doesn't look so essential anymore (if you only have a handful of arena lifetimes to track instead of thousands of individual object lifetimes, manual memory management becomes trivial too). E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). When I switched from 'mainly C++' back to 'mainly C' about 8 years ago, I *did* think that I would miss RAII the most, turns out it was a non-issue (the main thing is to stop thinking about programs as individual objects interacting with each other).
  - imtringued 2y ago
    I'm sorry, but I'm not really seeing it. How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. There is no difference. The only argument I see against RAII is that a kernel would be better off with explicit drop() calls, but that is about it. >E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). Okay, but I sure hope you are aware that this is a fringe opinion shared by very few people. The people who need to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies do in fact need that "power". E.g. the average webapp or webserver and C is a non-starter for anything that is internet connected. If I were to switch to C, the thing I would miss the most is the absence of antagonistic compilers.
eviks 2y ago
> personally hope that the Linux kernel never adopts any RAII, as I already have to waste way too much time for other slow software to load. The only irrelevant example given is that of a poorly written app (Visual Studio) when discussing GPU driver. So is the GPU driver written with RAII slow? Is there a faster non-RAII version?
- st3fan 2y ago
  Theoretical situations are the best way to kill innovative ideas prematurely.
bsder 2y ago
I'm more disappointed by someone who thinks that Rust macros are better than Zig comptime. Rust macros are, IMO, one of the weakest parts of the language. Sure, you can do anything. To do so, you have to atomize down to lexical atoms, rearrange everything, and feed a new set of lexical atoms back into the stream. And to do so, you have to pull in a bunch of crates related to syntax analysis that should really be a fundamental part of the compiler and are welded to the specific Rust version. Bleargh! Zig comptime has been a real breath of fresh air. It's great that it runs at compile time, and, if I need to debug it, I can generally force it to be runtime code. You write the same code you were going to write anyway without creating weird meta-languages that have a magic expansion phase that is impossible to debug.
- pdimitar 2y ago
  I agree about Rust macros. Hopefully they'll upstream stuff like `syn` (and hyper-optimize it) in the future. I appreciate the code generation abilities Rust macros give me but hell, they are difficult to wrap your head around even if you worked with them multiple times.
Luker88 2y ago
RAII is not unavoidable though. The whole point of being against RAII is that forcing it has downsides you can not get away from. but Rust has mem::forget, and it is not even unsafe (it is in std only currently, but I see no reason why the kernel can not have its own version) So this to me seems a pointless argument vs: * calling the equivalent of drop() manually every time, except in some cases * calling mem::forget only when you need it and have auto drop() everywhere else ...Maybe mem::forget has not taken hold as a pattern? Still, these arguments do not look very technical , and much more religious to me
- pdimitar 2y ago
  Yep, all of what you said PLUS the fact that you can just use arena allocations where you know you'll have to allocate hundreds / thousands of objects and then free them almost at the same time. The blog article's author even alludes to this, which makes the post kind of funny. He debunked his own argument and yet continues on as if he did not.
- laundmo 2y ago
  re: std::mem::forget not being used much On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level. And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.
pdimitar 2y ago
I am not sure what does this article achieve except cite other people's opinions on using or not using RAII (and a few other mechanisms). It even admits that using arena allocator in Rust would address most (if not all) of their reservations towards RAII. And mentioning that there are badly written programs out there that take a while to shut down is, while informative in terms of an anecdote, is at the same time not at all a firm evidence the same will happen in the kernel. I mean, it's the kernel, and the uttermost attention should be given to any potential performance or stability concerns -- of course! But it does not seem like the people against it are willing to gather data. Which again puts the Rust devs on the backfoot. Seems like constant impeding akin to a bureaucratic structure that knows that you'll eventually get what you came for but they'll put every obstacle possible on your path first. :( But overall, the article ended just when I expected it to get a bit more serious and data-oriented. Or at least give little more than opinions / feelings about the contention point.
hoseja 2y ago
[flagged]
SuperV1234 2y ago
Biased and unsubstantiated article, written by "VP of Community at the Zig Software Foundation". Lack of RAII in Zig is one of the reason why I refuse to write any software in it -- it's such a backwards design decision that throws decades of programming language safety in the bin. `defer` can be forgotten and is not enforced at compile-time, it's a terrible solution. Also, `defer` can be implemented in terms of RAII if needed. Yes, yes... arena allocation can be faster than deallocating every object one by one, Casey is a convincing/charismatic individual with extreme and biased opinions and an extremely narrow programming domain, can RAII can be misused and cause slowdowns. Every programmer that understands RAII knows these things. Guess what -- when provably better, you can use RAII for the whole arena and not each individual component. Also -- data oriented design is not inherently incompatible with abstractions and RAII. I'm tired of seeing all these misconceptions, when -- TBH -- it's mostly a skill issue.
QuadrupleA 2y ago
Beyond just performance, RAII (a cryptically named concept BTW) introduces a lot of implicit, indirect behavior, making code much more complicated and harder to reason about. When does your constructor & destructor fire when a dynamic array grows? Did you use the copy-and-swap idiom properly? Did you define all the "rule of five" methods? It's bonkers. I think a "defer" or "on scope exit" statement is just about ideal, gets you the same benefits but much more simply.
- Measter 2y ago
  > When does your constructor & destructor fire when a dynamic array grows? What constructor? And why would a Drop implementation be invoked to move something? You've moved it, there's nothing left to drop. > Did you use the copy-and-swap idiom properly? I don't believe I'm familiar with this idiom? From some quick googling this seems to be related to panic safety and ensuring that you don't leave things in an invalid state if a panic happens. It doesn't seem to be RAII-specific, and would also apply to a defer mechanism. > Did you define all the "rule of five" methods? Rule of five? You mean that your Clone implementation must properly handle resources in accordance with your Drop implementation, right? I'm not sure where the other three come in?
  - QuadrupleA 2y ago
    I'm speaking about C++, where blind faith in RAII is widespread, so I don't know if Rust's implementation alleviates some of the accidental complexity. But I suspect any system with constructors / destructors leads to a lot of the same implicit behaviors, unintended complications, and leaky abstractions, and I generally favor explicit Initialize() and Cleanup() functions that you call manually, even in languages that support the implicit/magic stuff.
    - estebank 2y ago
      Rust doesn't have constructors*. * Well, it kind of does, in so far there is a Ctor enum variant in the compiler implementation to represent the name of a type in the value namespace, but it is not overridable by end users and has no logic.
PeterWhittaker 2y ago
I'm even less sure what to make of this article after developments over the past two weeks and especially this past weekend: It seems to be mostly Rust FUD wrapped in a screed against RAII, implying that somehow Rust will harm the kernel, maybe. But in the past two weeks... 16 Nov, Linux 6.13 Introducing New Rust File Abstractions, https://www.phoronix.com/news/Linux-6.13-Rust-File-Abstract https://www.phoronix.com/news/Linux-6.13-Rust-File-Abstract 26 Nov, 3K Lines Of New Rust Infrastructure Code Head Into Linux 6.13, https://www.phoronix.com/news/Linux-6.13-Rust https://www.phoronix.com/news/Linux-6.13-Rust 30 Nov, Linux 6.13 Hits A "Tipping Point" With More Rust Drivers Expected Soon, https://www.phoronix.com/news/Linux-6.13-char-misc-More-Rust https://www.phoronix.com/news/Linux-6.13-char-misc-More-Rust That last one is particularly interesting, with the following quote from Greg K-H: "rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present. Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)"
- deagle50 2y ago
  > It seems to be mostly Rust FUD wrapped in a screed against RAII, implying that somehow Rust will harm the kernel, maybe Very interesting observation, I think you might be right.

98 points by _tbl6 2y ago

Except Arenas are well expressible in Rust. What's more, the fact that there are lifetime constraints allows to have both safe and idiomatic abstractions for them.

raggi 2y ago

This article implies that batch allocations are some kind of panacea and that raii has no place there. Neither of these implications have any case made for them, just links to other publications that do the same. It also alludes to downsides but fails to define them, and also misses documenting any downsides associated with alternatives. Despite deep familiarity with the space and understanding of both sides, I can’t really see it saying anything much at all in fact

raggi 2y ago
There’s a one-sentence implied claim in here that raii is the reason for c++ rejection and rejection of c++ implies rejection of raii. The author is clearly unaware of the recent cleanup attribute infrastructure submitted on the c side of the kernel: https://github.com/torvalds/linux/blob/master/include/linux/cleanup.h https://github.com/torvalds/linux/blob/master/include/linux/... Zig is a fun and interesting language in its own right, there’s really no need for this post-truth era style propaganda. Just focus on your own work
mathw 2y ago
Basically the same conclusion I came to, I was hoping the article would really make a point at some stage but it just fizzled out without really asserting anything with any supporting evidence. I particularly didn't enjoy how it completely failed to take into account the well-established practice of using RAII alongside arena allocation in C++...

sunshowers 2y ago

> The fact that Rust developers who are interfacing with the Linux project seem completely unaware of the downsides of RAII, reminds me of when the US ambassador to Denmark thought that their collaborators biked to work because they were too poor to own a car. I would imagine kernel developers working with Rust are quite aware of the downsides of RAII when it comes to large synchronous drops, and aware of arena allocation patterns. They are also likely aware of both arenas that run destructors on drop, and arenas that don't, and the relative merits of each. They are also likely aware of arenas that you can garbage collect over time, as enabled via generational index patterns. The good news is that if profiling shows this to be a bottleneck, it is relatively easy to safely switch code that does allocations to using an arena instead (you'd have to add a lifetime parameter to everything tied to the arena). RAII remains a great way to solve many real problems in systems programming, and banning tools which enable it on the off chance that you'd run into performance issues with synchronous drops, without any data to back it up, doesn't seem wise.

perching_aix 2y ago
The author's line of thought seems to be concerned with the social aspect of RAII in my reading though. Like how you can write memory-safe C if you're a "good C programmer" (meaning most people evidently won't), these considerations for RAII might be subtle enough that it justifies banning its use altogether (like using memory unsafe constructions is in safe Rust).
- sunshowers 2y ago
  A sibling comment [1] points out that the kernel recently gained some RAII-like functionality. The typical alternative to RAII-based error handling in C tends to be goto statements. I'm sure those of us who have written C are used to writing goto statements in inverse order for their error handling -- and we've also made mistakes with them especially when there's a lot of branching paths (or at least I have). In comparison to that I personally appreciate RAII quite a lot. Even with arena allocation, it may make sense to have a struct be composed of some memory that's borrowed from the arena and some that's owned by the struct. That works exactly as you'd expect in Rust. [1] https://news.ycombinator.com/item?id=42291921 https://news.ycombinator.com/item?id=42291921

diath 2y ago

I've always wondered why not just fork Linux and add Rust there then keep it in sync with mainline and maintain it long time to demonstrate that it's a viable strategy and there's enough volunteers willing to actually spend their time instead of turning the Rust part of the kernel into abandonware when there's so few developers available, before trying to get it supported upstream?

0cf8612b2e1e 2y ago
Just fork one of the largest open source projects in the world? Linux has many contributors who are paid full time to improve the project. Something that is impossible to match in a sideshow project.
- diath 2y ago
  Exactly my point, if that cannot be done as a third party project, then shoehorning Rust into Linux and expecting unpaid third party volunteers to actually maintain it makes no sense. Unless a big corp steps up to fund such efforts, it's pointless.
  - lesuorac 2y ago
    It's Linus's project. He wants to allow Rust. If you don't then you fork it into your own project lol ...
  - sunshowers 2y ago
    Linus has already decided to accept Rust! A fork would simply not be practical. Disagree and commit.
    - tkahf 2y ago
      How much of that is the opinion of the corporate masters who fund the Linux Foundation? Why Rust and not Ada for example? Rust is heavily promoted by web developers who call the shots these days because they bring in the advertising money. I find it hard to believe that Rust is the end of all other languages, especially given its ugly syntax.

wk_end 2y ago

The author of this is the VP of Community for Zig; his only professional experience, according to LinkedIn, is in similar advocacy roles. It's an incredibly bad look for the Zig community then, in my opinion, for him - somewhat sarcastically and disrespectfully ("oh no!", "I already have to waste way too much time for other slow software to load") - trying to school Asahi Lina on "writing performance-oriented software" when she's one of the most impressive software engineers in the public eye right now. This is just a FUD-y hit piece on RAII. It, frankly, smacks of Dunning Kruger (I know, not statistically a real thing, but rhetorically useful): a writer way beyond his depth hears someone praise RAII, and out of ignorance and professional obligations launches an attack by linking some canned "RAII Bad" sources, not realizing the person they're attacking knows vastly more about...well, basically everything, than they do.

sunshowers 2y ago
Oh, I didn't realize that. I guess I should add a disclaimer then: a mean and condescending tweet from him caused me to withdraw my sponsorship of Zig a couple of years ago.
- deleted 2y ago
  [deleted]
pseudony 2y ago
This is not his best post, granted (there are some good ones). That said, I think this is a very uncharitable read and resorting to ad hominom (he's not a real dev!) is uncalled for. If you think the argument is wrong -say so. Refute it on its own merits. It gets no better or worse from it being said by him. That also goes for Asahi lina - I find it so incredibly tiring when people's hero-worshipping of this admittedly great developer extends to thinking they are simply right about everything. Carmack is a great dev, he likes his C and C++. Alexis King (Lexi Lambda) used to be a top lisper (likely still is), now a great haskeller. Rich Hickey and so on and so on. Point is - how do ypu reconcile the fact that these people hold wildly different ideas on what makes good programming and programning languages, some of them even changing opinions over their lifetimes. Will you create a programmer godhood pantheon and claim Asahi Lina is the smartest person ever or write it off as "systems programming must be Rust"? I am curious. Anyway, not aimed at singling you out, but the appeal to authority (Lina) as some way of saying " this is right, everyone else are wrong" is shoddy arguing.

MuffinFlavored 2y ago

> RAII Resource acquisition is initialization

Ericson2314 2y ago
The name is terrible, all the more so because we are talking about deacquisition and deinitialization most of the time.
- pclmulqdq 2y ago
  RAII is really all about the deconstructors, not the constructors.
- justincredible 2y ago
  [dead]

matt3210 2y ago

Imagine this: we have a group of friends and we’re having a good time. We all speak English. One or two guys invite some people who are always speaking in Klingon. They invite more and now a large amount of the group wants to have equal support in d&d and other activities for Klingon. They insist it’s a better language when it’s only just a different language, not better or worse. The English speakers are trying to stop the Klingon speakers from changing their group to something new that they don’t like (and not provably better). Rust is Klingon. C is working fine and is the language everyone is already familiar with. If Rust was actually better, it would flow into the ground organically. Being technically more memory safe doesn’t make people like it more. Proper tooling with C can prevent memory issues, taking away the main argument for rust. In the end we don’t need any more of a reason to stop rust other than “we don’t like rust”.

perching_aix 2y ago
> If Rust was actually better, it would flow into the ground organically. What would Rust flowing into the Linux kernel organically look like in your opinion? On a similar note, I work in a non-English speaking country, but have developed a real bad habit of sticking to English when it comes to technical discussions (work or non-work). Mind you, this is an international company we work at, proficiency in English is expected (and often lackluster). My colleagues don't appreciate this, and will poke fun at it from time to time. They're convinced I'm being obnoxious on purpose, despite me just spending 90% of my day interacting with English in English. It is only natural then that I keep thinking about things in English. What you'll discover is that these colleagues of mine have two things in common: they're not anywhere nearly as immersed and proficient in English as I am despite working here for a decade, and that they're a bit of an old-timer jackass types. This was not metaphor.
- matt3210 2y ago
  I don’t know what it looks like, but it’s definitely not forcing people to accept it. Rust right now just isn’t in a form that some (I personally think most) people can accept. Maybe it’s just that it’s so not-c-like. … given your language examples, maybe the main issue is just that rust is just so different. I personally find the rust language to be non intuitive… but what’s intuitive for me is heavily informed by c/c++ or python

jitl 2y ago

This is a very silly straw man. RAII style is a syntax feature that doesn’t imply a specific semantics for how big the “resource” is, or how it’s allocated or freed. The only difference in Rust versus Zig is that Rust calls the de-allocator automatically and invisibly, and Zig requires allocation use an allocator parameter and an explicit call to free. Neither forces you to allocate batches at a time, nor do they prevent batching or use of arenas. To me it seems just as easy to allocate MyStruct[100] in either language.

csb6 2y ago
Exactly - people seem to assume that RAII means having to heap allocate each object individually and then having to deallocate each object individually when done. Clearly that is not true and the allocation patterns are orthogonal to whether RAII is used. RAII is also useful for non-memory related tasks like unlocking mutexes once the lock is no longer needed, which is just plainly useful in any language that allows functions to have multiple exit points.
- jitl 2y ago
  I would prefer explicit linear types for locks, I find following Rust code using locks is very confusing - like an compiler-enforced call to `defer drop(lock)` to make it clear how it works. But I'm a noob at Rust.
- ozgrakkurt 2y ago
  A lot of concepts don’t directly mean you have to write bad code but they push you in that direction. Fact is, arena allocation or any other kind of custom allocation is pretty much non-existent in rust. Hopefully it will be implemented soon but I’m not sure if it is feasible because of lifetimes
  - whytevuhuni 2y ago
    How so? I've been using arena allocation with the bumpalo crate [1] with great success. I also wrote my own arena allocator for a WASM project, and also wrapped Nginx's memory pool via safe APIs. I'm not going to claim that writing one correctly is easy... much like writing any low-level allocators, you have to deal with layout, drop order, unsafe cells, etc. But using them? The lifetimes work great with them. And the allocator trait [2], once released, will make it so std collection types can be used as well. [1] https://docs.rs/bumpalo https://docs.rs/bumpalo [2] https://doc.rust-lang.org/std/alloc/trait.Allocator.html https://doc.rust-lang.org/std/alloc/trait.Allocator.html

actuallyalys 2y ago

The confusing part of this article is the argument that the kernel maintainers are strongly against RAII. While I guess it’s possible Asahi Lina is unaware of this or is stubbornly including it anyway because she believes it’s such a large benefit, it seems more likely that it isn’t actually the dealbreaker. In fairness, I’m hardly an expert on C++, Rust, or kernel development, so it’s possible that I’m missing something.

MuffinFlavored 2y ago
> it seems more likely that it isn’t actually the dealbreaker. What is the dealbreaker then?
- actuallyalys 2y ago
  I’m not sure. One point I agree with the author is that it’s a complicated situation likely involving both social and technical factors.
- sunshowers 2y ago
  I think C++ drags a lot of bad stuff in with the good, and it is reasonable to be skeptical of it. For example, I think it was bordering on malpractice for lambdas to ship without anything resembling a borrow checker in place. With lambdas that borrow from the stack, introducing memory safety bugs is shockingly trivial. Even if your codebase bans lambdas in C++, it's quite reasonable to not fully trust the teams which made the decision to ship them.

quotemstr 2y ago

This is a "Structure of Scientific Revolutions" scenario: https://press.uchicago.edu/ucp/books/book/chicago/S/bo13179781.html https://press.uchicago.edu/ucp/books/book/chicago/S/bo131797... In any field, be it engineering or the sciences, accomplished and intelligent practitioners find themselves resisting new technology for reasons that are ultimately inscrutable and personal --- for example, fear of the unknown or fear of new technology devaluing their in the old. Because these practitioners are experienced and intelligent, they're able to construct elaborate plausible-sounding technical arguments against the new technologies. But since they're starting with the opposition and working backwards to a rationale, what these practitioners do when they argue against the new technology isn't so much science as apologetics. Apologies can be frustrating because, superficially, they resemble earnest argumentation --- but because, in apologetics, the authors starts with a conclusion and works backwards to an argument, an apology contains insidious logical traps that are difficult to detect and disarm, especially when the new technology (as all new technologies do) contain genuine gaps and flaws. It's because of this dynamic that many fields advance "one retirement at a time". We should all make a conscious effort, when evaluating new technology, to distinguish earnest technical criticisms from justifications for feeling averse to change --- and consciously suppress the latter.

alextingle 2y ago
Are you saying that RAII is "new technology"??
- quotemstr 2y ago
  If you're a lifelong ANSI C programmer, RAII is new and scary.

asveikau 2y ago

RAII is all about making the compiler do what the "disciplined" C code is already doing manually. As mentioned elsewhere in this thread, a common C coding style and idiom is to goto to the end of your scope, where all the free calls go. The resulting behavior is pretty close to RAII. The argument in favor of RAII is that it's a lot less error prone to let the compiler write that part for you. A fine goal of course, but I feel like this post is overstating it or perhaps conflating it with something else (eg. The aside about trying to convince the GPU API maintainer that the issues they hit are also affecting drivers written in C may have little or nothing to do with rust or RAII)

flohofwoe 2y ago
The problem is that since cleanup with RAII is so 'simple', you tend to forget about it, and then you're suddenly in a situation where destroying a single object results in a cascade of thousands of other tiny destructions. So now you actually need to think about a proper memory management strategy (even though you have automatic memory management) and will eventually arrive at arenas as the solution, and once you're there, suddenly RAII doesn't look so essential anymore (if you only have a handful of arena lifetimes to track instead of thousands of individual object lifetimes, manual memory management becomes trivial too). E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). When I switched from 'mainly C++' back to 'mainly C' about 8 years ago, I *did* think that I would miss RAII the most, turns out it was a non-issue (the main thing is to stop thinking about programs as individual objects interacting with each other).
- imtringued 2y ago
  I'm sorry, but I'm not really seeing it. How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. There is no difference. The only argument I see against RAII is that a kernel would be better off with explicit drop() calls, but that is about it. >E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). Okay, but I sure hope you are aware that this is a fringe opinion shared by very few people. The people who need to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies do in fact need that "power". E.g. the average webapp or webserver and C is a non-starter for anything that is internet connected. If I were to switch to C, the thing I would miss the most is the absence of antagonistic compilers.

eviks 2y ago

> personally hope that the Linux kernel never adopts any RAII, as I already have to waste way too much time for other slow software to load. The only irrelevant example given is that of a poorly written app (Visual Studio) when discussing GPU driver. So is the GPU driver written with RAII slow? Is there a faster non-RAII version?

st3fan 2y ago
Theoretical situations are the best way to kill innovative ideas prematurely.

bsder 2y ago

I'm more disappointed by someone who thinks that Rust macros are better than Zig comptime. Rust macros are, IMO, one of the weakest parts of the language. Sure, you can do anything. To do so, you have to atomize down to lexical atoms, rearrange everything, and feed a new set of lexical atoms back into the stream. And to do so, you have to pull in a bunch of crates related to syntax analysis that should really be a fundamental part of the compiler and are welded to the specific Rust version. Bleargh! Zig comptime has been a real breath of fresh air. It's great that it runs at compile time, and, if I need to debug it, I can generally force it to be runtime code. You write the same code you were going to write anyway without creating weird meta-languages that have a magic expansion phase that is impossible to debug.

pdimitar 2y ago
I agree about Rust macros. Hopefully they'll upstream stuff like `syn` (and hyper-optimize it) in the future. I appreciate the code generation abilities Rust macros give me but hell, they are difficult to wrap your head around even if you worked with them multiple times.

Luker88 2y ago

RAII is not unavoidable though. The whole point of being against RAII is that forcing it has downsides you can not get away from. but Rust has mem::forget, and it is not even unsafe (it is in std only currently, but I see no reason why the kernel can not have its own version) So this to me seems a pointless argument vs: * calling the equivalent of drop() manually every time, except in some cases * calling mem::forget only when you need it and have auto drop() everywhere else ...Maybe mem::forget has not taken hold as a pattern? Still, these arguments do not look very technical , and much more religious to me

pdimitar 2y ago
Yep, all of what you said PLUS the fact that you can just use arena allocations where you know you'll have to allocate hundreds / thousands of objects and then free them almost at the same time. The blog article's author even alludes to this, which makes the post kind of funny. He debunked his own argument and yet continues on as if he did not.
laundmo 2y ago
re: std::mem::forget not being used much On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level. And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.

pdimitar 2y ago

I am not sure what does this article achieve except cite other people's opinions on using or not using RAII (and a few other mechanisms). It even admits that using arena allocator in Rust would address most (if not all) of their reservations towards RAII. And mentioning that there are badly written programs out there that take a while to shut down is, while informative in terms of an anecdote, is at the same time not at all a firm evidence the same will happen in the kernel. I mean, it's the kernel, and the uttermost attention should be given to any potential performance or stability concerns -- of course! But it does not seem like the people against it are willing to gather data. Which again puts the Rust devs on the backfoot. Seems like constant impeding akin to a bureaucratic structure that knows that you'll eventually get what you came for but they'll put every obstacle possible on your path first. :( But overall, the article ended just when I expected it to get a bit more serious and data-oriented. Or at least give little more than opinions / feelings about the contention point.

hoseja 2y ago

[flagged]

SuperV1234 2y ago

Biased and unsubstantiated article, written by "VP of Community at the Zig Software Foundation". Lack of RAII in Zig is one of the reason why I refuse to write any software in it -- it's such a backwards design decision that throws decades of programming language safety in the bin. `defer` can be forgotten and is not enforced at compile-time, it's a terrible solution. Also, `defer` can be implemented in terms of RAII if needed. Yes, yes... arena allocation can be faster than deallocating every object one by one, Casey is a convincing/charismatic individual with extreme and biased opinions and an extremely narrow programming domain, can RAII can be misused and cause slowdowns. Every programmer that understands RAII knows these things. Guess what -- when provably better, you can use RAII for the whole arena and not each individual component. Also -- data oriented design is not inherently incompatible with abstractions and RAII. I'm tired of seeing all these misconceptions, when -- TBH -- it's mostly a skill issue.

QuadrupleA 2y ago

Beyond just performance, RAII (a cryptically named concept BTW) introduces a lot of implicit, indirect behavior, making code much more complicated and harder to reason about. When does your constructor & destructor fire when a dynamic array grows? Did you use the copy-and-swap idiom properly? Did you define all the "rule of five" methods? It's bonkers. I think a "defer" or "on scope exit" statement is just about ideal, gets you the same benefits but much more simply.

Measter 2y ago
> When does your constructor & destructor fire when a dynamic array grows? What constructor? And why would a Drop implementation be invoked to move something? You've moved it, there's nothing left to drop. > Did you use the copy-and-swap idiom properly? I don't believe I'm familiar with this idiom? From some quick googling this seems to be related to panic safety and ensuring that you don't leave things in an invalid state if a panic happens. It doesn't seem to be RAII-specific, and would also apply to a defer mechanism. > Did you define all the "rule of five" methods? Rule of five? You mean that your Clone implementation must properly handle resources in accordance with your Drop implementation, right? I'm not sure where the other three come in?
- QuadrupleA 2y ago
  I'm speaking about C++, where blind faith in RAII is widespread, so I don't know if Rust's implementation alleviates some of the accidental complexity. But I suspect any system with constructors / destructors leads to a lot of the same implicit behaviors, unintended complications, and leaky abstractions, and I generally favor explicit Initialize() and Cleanup() functions that you call manually, even in languages that support the implicit/magic stuff.
  - estebank 2y ago
    Rust doesn't have constructors*. * Well, it kind of does, in so far there is a Ctor enum variant in the compiler implementation to represent the name of a type in the value namespace, but it is not overridable by end users and has no logic.

PeterWhittaker 2y ago

I'm even less sure what to make of this article after developments over the past two weeks and especially this past weekend: It seems to be mostly Rust FUD wrapped in a screed against RAII, implying that somehow Rust will harm the kernel, maybe. But in the past two weeks... 16 Nov, Linux 6.13 Introducing New Rust File Abstractions, https://www.phoronix.com/news/Linux-6.13-Rust-File-Abstract https://www.phoronix.com/news/Linux-6.13-Rust-File-Abstract 26 Nov, 3K Lines Of New Rust Infrastructure Code Head Into Linux 6.13, https://www.phoronix.com/news/Linux-6.13-Rust https://www.phoronix.com/news/Linux-6.13-Rust 30 Nov, Linux 6.13 Hits A "Tipping Point" With More Rust Drivers Expected Soon, https://www.phoronix.com/news/Linux-6.13-char-misc-More-Rust https://www.phoronix.com/news/Linux-6.13-char-misc-More-Rust That last one is particularly interesting, with the following quote from Greg K-H: "rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present. Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)"

deagle50 2y ago
> It seems to be mostly Rust FUD wrapped in a screed against RAII, implying that somehow Rust will harm the kernel, maybe Very interesting observation, I think you might be right.