4 ms·

I’ve been learning Rust via the book and a great article I found on linked lists [1]. Coming from C++ the lifetimes/borrows concepts make sense at a high level

I’ve been learning Rust via the book and a great article I found on linked lists [1]. Coming from C++ the lifetimes/borrows concepts make sense at a high level but the practical details seem to get pretty crazy. If anyone here knows Rust well does the OP article have a good take or is it missing something? [1] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/

scottlamb 1y ago
I think if you've hit this problem and are looking for solutions, this article looks like a helpful read. There are lots of ideas there. I wouldn't say this is a super common problem (though I have hit it). The opening example here is that logic outside `Parent` is maintaining its summary state based on its children. That's unusual; typically `Parent` itself would be responsible for that, and so you can inline the logic without having to expose the fields. Sometimes inlining the logic gets impractical though if the logic is super long. In that case it can be helpful to split it into sub-structs so that you can easily call a method on a group of fields. I did that here, for example: <https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7e2d9b956b3798d8a6013fcfefe5/server/src/mp4.rs#L647 https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7...> There have been language proposals to define "view types" which are basically groups of fields that are borrowed. <https://smallcultfollowing.com/babysteps/blog/2021/11/05/view-types/ https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie...> IMHO, they're not worth the extra language complexity.
recursivecaveat 1y ago
This actually seems like a very good collection of strategies. The only one I use that I see missing is converting a closure capture into an argument. If you design something like: zebra.onmove(|| log(barn.contains(zebra))), then you will find everything locks up due to the references of the closure. Instead you convert the data to args: zebra.onmove(|world, zebra| log(world.barn.contains(zebra))). Obviously with cheap data which you can freeze and copy like a BarnId it's fine to do that. In general, "stop, drop, reacquire" is a good motto. ie finish figuring out what you want to happen, release the resources that you needed to figure that out, reacquire exactly the resources you need to make the thing happen, do it. That's basically the premise of 'mutation-as-data'.
- qouteall 1y ago
  Thanks for suggestion.
deleted 1y ago
[deleted]

scottlamb 1y ago

I think if you've hit this problem and are looking for solutions, this article looks like a helpful read. There are lots of ideas there. I wouldn't say this is a super common problem (though I have hit it). The opening example here is that logic outside `Parent` is maintaining its summary state based on its children. That's unusual; typically `Parent` itself would be responsible for that, and so you can inline the logic without having to expose the fields. Sometimes inlining the logic gets impractical though if the logic is super long. In that case it can be helpful to split it into sub-structs so that you can easily call a method on a group of fields. I did that here, for example: <https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7e2d9b956b3798d8a6013fcfefe5/server/src/mp4.rs#L647 https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7...> There have been language proposals to define "view types" which are basically groups of fields that are borrowed. <https://smallcultfollowing.com/babysteps/blog/2021/11/05/view-types/ https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie...> IMHO, they're not worth the extra language complexity.

recursivecaveat 1y ago

This actually seems like a very good collection of strategies. The only one I use that I see missing is converting a closure capture into an argument. If you design something like: zebra.onmove(|| log(barn.contains(zebra))), then you will find everything locks up due to the references of the closure. Instead you convert the data to args: zebra.onmove(|world, zebra| log(world.barn.contains(zebra))). Obviously with cheap data which you can freeze and copy like a BarnId it's fine to do that. In general, "stop, drop, reacquire" is a good motto. ie finish figuring out what you want to happen, release the resources that you needed to figure that out, reacquire exactly the resources you need to make the thing happen, do it. That's basically the premise of 'mutation-as-data'.

qouteall 1y ago
Thanks for suggestion.

deleted 1y ago

[deleted]