5 ms·

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

by 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.
  - sunshowers 2y ago
    Oh interesting, in what other threads have I shown up? I would trust her general judgment based on a complex list of factors, including my own personal experience and how my own understanding of the world aligns with hers. I'm exercising my own judgment honed over time.
  - st3fan 2y ago
    Because it is working code. Not just talk.
bsder 2y ago
> In addition to that, I feel like pointing out that destructors generally compile down to nothing. Really? If that's true then RAII didn't do anything in the first place and you could do without it. And the "everybody uses goto" is a "defer/errdefer" pattern rather than an RAII pattern. So, in at least 2/3 of the cases, you don't need the full power of RAII and all the problems it brings. > 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. The big failure point is when your RAII object escapes local scope (ie. you pass it back or put it into a container data structure). RAII means that the entity who gets charged with deallocation is different form the entity who created the allocation. This is the exact same problem as the old C problem of "allocate an object in one function but expect a different function to deallocate it". C old timers excoriate anyone who does this for good reason. Sure, RAII in Rust means you don't core dump; your performance characteristics just become non-deterministic. This kind of cleanup action at a distance is essentially "garbage collection" by any other name--only less well controlled. Quite often the whole point of using a systems programming language is to avoid garbage collection non-determinism--that chunk of people are going to be very upset to see it come back via RAII.
- sunshowers 2y ago
  I find it quite nice that I can return owned resources and don't have to pass in buffers for all my out params :) I'm sensitive to action at a distance problems, but I don't really think this is one. In practice I think the ability to return owned resources leads to better, more scalable development.

by gary_0 2y ago

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.
- sunshowers 2y ago
  Oh interesting, in what other threads have I shown up? I would trust her general judgment based on a complex list of factors, including my own personal experience and how my own understanding of the world aligns with hers. I'm exercising my own judgment honed over time.
- st3fan 2y ago
  Because it is working code. Not just talk.

bsder 2y ago

> In addition to that, I feel like pointing out that destructors generally compile down to nothing. Really? If that's true then RAII didn't do anything in the first place and you could do without it. And the "everybody uses goto" is a "defer/errdefer" pattern rather than an RAII pattern. So, in at least 2/3 of the cases, you don't need the full power of RAII and all the problems it brings. > 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. The big failure point is when your RAII object escapes local scope (ie. you pass it back or put it into a container data structure). RAII means that the entity who gets charged with deallocation is different form the entity who created the allocation. This is the exact same problem as the old C problem of "allocate an object in one function but expect a different function to deallocate it". C old timers excoriate anyone who does this for good reason. Sure, RAII in Rust means you don't core dump; your performance characteristics just become non-deterministic. This kind of cleanup action at a distance is essentially "garbage collection" by any other name--only less well controlled. Quite often the whole point of using a systems programming language is to avoid garbage collection non-determinism--that chunk of people are going to be very upset to see it come back via RAII.

sunshowers 2y ago
I find it quite nice that I can return owned resources and don't have to pass in buffers for all my out params :) I'm sensitive to action at a distance problems, but I don't really think this is one. In practice I think the ability to return owned resources leads to better, more scalable development.