6 ms·

> 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 ambassado

> 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
  - perching_aix 2y ago
    This doesn't quite address what I wrote about specifically.
    - sunshowers 2y ago
      I'm quite sympathetic to social effects of technical choices in general! You said: > 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). In response I gave you a link which (if you follow it) says: * The "goto error" pattern is notorious for introducing subtle resource * leaks. It is tedious and error prone to add new resource acquisition * constraints into code paths that already have several unwind * conditions. The "cleanup" helpers enable the compiler to help with * this tedium and can aid in maintaining LIFO (last in first out) * unwind ordering to avoid unintentional leaks. So clearly this is about understanding that goto-based error handling doesn't really scale and adding RAII-like behavior to make it work better.
      - perching_aix 2y ago
        What you linked to / cite doesn't address what I was talking about either. I understand that you believe it does, so let me clarify why I think it doesn't. On the top level, you wrote: > 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. Thing is, I'm not nearly familiar enough on a low level with constructs like RAII - however, I think this is actually working in my advantage in this case. Because to me what you wrote reads like this: - RAII in certain scenarios should be avoided - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) - arenas running destructors on drop in certain scenarios should be avoided - those scenarios are also mindware (and we just trust that kernel devs can and will recall it as appropriate) Crucially, none of this is about whether RAII is better than any alternative (relative value), but is about its properties (absolute value). This is also not incompatible with what the article says, in fact, I believe is what the article was sort of peddling inadvertently. And so my comment was about relating this to the memory management of C in principle. That the flow of the argument (I think) is similar. That the correctness is dependent on the programmer attention (and their correct usage of tooling), while also being high on the skill tree. Now, I understand if this comes off as an extremely unrevelatory discovery, or if you feel different about the likelihoods involved. But I found it fascinating, if not equally fearsome.
gary_0 2y ago
In addition to that, I feel like pointing out that destructors generally compile down to nothing. I have mostly only seen issues with "heavy destructors" in old-school C++ code where you have lots of small allocations and complicated trees of object ownership--which is a model Rust discourages! I think the anti-Rust people would be better off arguing that they just don't like RAII because it's "magic" (ie. too implicit about cleanup). It's harder to argue against because it's subjective, whereas these arguments against RAII are specious at best.
- sunshowers 2y ago
  Agreed (I think arena-style "allocation at the top" makes Rust significantly nicer to write in general, and I borrow from a big chunk of the data at the top quite frequently), though in this case what Lina was describing sounded somewhat close to the big tree of allocations. Now, it could be any or all of: * inherently required by the hardware, in which case all you can do is shrug * good for a first-pass implementation and maybe optimized in the future * simply not an issue in practice. Without more information, I would trust that Lina made the right decisions and/or will revise her decisions over time based on data.
  - gary_0 2y ago
    My impression was just that it was the cleanest way for her to map things on top of the existing kernel structures (which are probably tree-ish). And I highly doubt that there are any actual issues with this aspect of her design; it was just picked out as a contrived example by the blog post. I suspect if Lina's DRM patches had not come from a Rust dev or invoked "RAII theory", and were only advertised as improvements for clarity and conformance with expected behavior, they probably would have been accepted far sooner. (She says as much in her Mastodon post.)
  - Longlius 2y ago
    Why would you trust that Lina made the right decisions? Is it simply because of her past work? Even experienced engineers regularly make mistakes. It seems like you show up in these threads to give Lina all the benefit of the doubt and her detractors none.
ozgrakkurt 2y ago
It is not relatively easy to switch to arenas in rust at all. It is more time consuming compared to Zig for example. There is a reason almost no one implements it in rust. Even libraries like apache arrow and related query engines don’t implement it.

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
- perching_aix 2y ago
  This doesn't quite address what I wrote about specifically.
  - sunshowers 2y ago
    I'm quite sympathetic to social effects of technical choices in general! You said: > 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). In response I gave you a link which (if you follow it) says: * The "goto error" pattern is notorious for introducing subtle resource * leaks. It is tedious and error prone to add new resource acquisition * constraints into code paths that already have several unwind * conditions. The "cleanup" helpers enable the compiler to help with * this tedium and can aid in maintaining LIFO (last in first out) * unwind ordering to avoid unintentional leaks. So clearly this is about understanding that goto-based error handling doesn't really scale and adding RAII-like behavior to make it work better.
    - perching_aix 2y ago
      What you linked to / cite doesn't address what I was talking about either. I understand that you believe it does, so let me clarify why I think it doesn't. On the top level, you wrote: > 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. Thing is, I'm not nearly familiar enough on a low level with constructs like RAII - however, I think this is actually working in my advantage in this case. Because to me what you wrote reads like this: - RAII in certain scenarios should be avoided - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) - arenas running destructors on drop in certain scenarios should be avoided - those scenarios are also mindware (and we just trust that kernel devs can and will recall it as appropriate) Crucially, none of this is about whether RAII is better than any alternative (relative value), but is about its properties (absolute value). This is also not incompatible with what the article says, in fact, I believe is what the article was sort of peddling inadvertently. And so my comment was about relating this to the memory management of C in principle. That the flow of the argument (I think) is similar. That the correctness is dependent on the programmer attention (and their correct usage of tooling), while also being high on the skill tree. Now, I understand if this comes off as an extremely unrevelatory discovery, or if you feel different about the likelihoods involved. But I found it fascinating, if not equally fearsome.

gary_0 2y ago

In addition to that, I feel like pointing out that destructors generally compile down to nothing. I have mostly only seen issues with "heavy destructors" in old-school C++ code where you have lots of small allocations and complicated trees of object ownership--which is a model Rust discourages! I think the anti-Rust people would be better off arguing that they just don't like RAII because it's "magic" (ie. too implicit about cleanup). It's harder to argue against because it's subjective, whereas these arguments against RAII are specious at best.

sunshowers 2y ago
Agreed (I think arena-style "allocation at the top" makes Rust significantly nicer to write in general, and I borrow from a big chunk of the data at the top quite frequently), though in this case what Lina was describing sounded somewhat close to the big tree of allocations. Now, it could be any or all of: * inherently required by the hardware, in which case all you can do is shrug * good for a first-pass implementation and maybe optimized in the future * simply not an issue in practice. Without more information, I would trust that Lina made the right decisions and/or will revise her decisions over time based on data.
- gary_0 2y ago
  My impression was just that it was the cleanest way for her to map things on top of the existing kernel structures (which are probably tree-ish). And I highly doubt that there are any actual issues with this aspect of her design; it was just picked out as a contrived example by the blog post. I suspect if Lina's DRM patches had not come from a Rust dev or invoked "RAII theory", and were only advertised as improvements for clarity and conformance with expected behavior, they probably would have been accepted far sooner. (She says as much in her Mastodon post.)
- Longlius 2y ago
  Why would you trust that Lina made the right decisions? Is it simply because of her past work? Even experienced engineers regularly make mistakes. It seems like you show up in these threads to give Lina all the benefit of the doubt and her detractors none.

ozgrakkurt 2y ago

It is not relatively easy to switch to arenas in rust at all. It is more time consuming compared to Zig for example. There is a reason almost no one implements it in rust. Even libraries like apache arrow and related query engines don’t implement it.