3 ms·

Rust is least ergonomic when you're fighting with the borrow checker. It might be an interesting strategy to wrap shared objects with Gc<> or Rc<> by default t

Rust is least ergonomic when you're fighting with the borrow checker. It might be an interesting strategy to wrap shared objects with Gc<> or Rc<> by default to sidestep the fight. Once you've discovered the slowest parts of your codebase, you could refactor to replace Gc/Rc with zero-cost borrows or well-placed copies. I haven't tried this myself, but I'm surprised it isn't the standard operating procedure for (non-embedded) Rust programmers.

amelius 4y ago
We should probably have functional programming by default for sanity, wrapping Rust inside it for the speed in inner loops.
- bqmjjx0kac 4y ago
  Hmm, functional in what sense? Like functions should be pure by default, optionally annotated `impure` or something?
  - amelius 4y ago
    In the sense of allowing at least closures that are garbage collected (without them you can't idiomatically program in a modern functional style)
btown 4y ago
I think one of the issues is that Rc and Gc are not particularly ergonomic! Used at scale, they add noise/non-readability to any screen of code (Rc::clone, the various approaches for Gc in [0], for instance) that simply wouldn't be there in a dynamic language. Now, one might argue that this explicitness is good! But it's definitely an extra bunch of things to type when you're building something where you don't care about memory management. [0] https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/ https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...
- zozbot234 4y ago
  FWIW, there's a newer concurrent cycle-tracing GC for Rust known as Samsara. Writeup here: https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ It seems that it manages to be more efficient and intuitive to use compared to earlier approaches.
- amelius 4y ago
  Perhaps Rust syntax could be enhanced to make Gc more ergonomic?
vlovich123 4y ago
It’s an interesting idea but not sure it works in all spaces. If the goal of something that you’re building is performance, it’s really really hard to convince architectural and API missteps if you’re just liberally throwing around arc everywhere. Additionally, the amount of code you find out you have to rewrite is quite large. A better idea is to recognize where you’re bottlenecks are likely to be and where they’re not and use Rc is the clearly not case, be careful about it in the questionable cases and avoid it like the plague in the cases where it’s a problem. unsafe { std::transmute(x) } is my favorite go to if I’m sure I have the lifetime mechanics sorted and don’t want to fight the borrow checker right now (oh, and usually the borrow checker is right and I think I’ve done this like maybe 2-3 times where it’s really impossible to convey to the compiler what I’m trying to do, at least with my knowledge of Rust)

amelius 4y ago

We should probably have functional programming by default for sanity, wrapping Rust inside it for the speed in inner loops.

bqmjjx0kac 4y ago
Hmm, functional in what sense? Like functions should be pure by default, optionally annotated `impure` or something?
- amelius 4y ago
  In the sense of allowing at least closures that are garbage collected (without them you can't idiomatically program in a modern functional style)

btown 4y ago

I think one of the issues is that Rc and Gc are not particularly ergonomic! Used at scale, they add noise/non-readability to any screen of code (Rc::clone, the various approaches for Gc in [0], for instance) that simply wouldn't be there in a dynamic language. Now, one might argue that this explicitness is good! But it's definitely an extra bunch of things to type when you're building something where you don't care about memory management. [0] https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/ https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

zozbot234 4y ago
FWIW, there's a newer concurrent cycle-tracing GC for Rust known as Samsara. Writeup here: https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ It seems that it manages to be more efficient and intuitive to use compared to earlier approaches.
amelius 4y ago
Perhaps Rust syntax could be enhanced to make Gc more ergonomic?

vlovich123 4y ago

It’s an interesting idea but not sure it works in all spaces. If the goal of something that you’re building is performance, it’s really really hard to convince architectural and API missteps if you’re just liberally throwing around arc everywhere. Additionally, the amount of code you find out you have to rewrite is quite large. A better idea is to recognize where you’re bottlenecks are likely to be and where they’re not and use Rc is the clearly not case, be careful about it in the questionable cases and avoid it like the plague in the cases where it’s a problem. unsafe { std::transmute(x) } is my favorite go to if I’m sure I have the lifetime mechanics sorted and don’t want to fight the borrow checker right now (oh, and usually the borrow checker is right and I think I’ve done this like maybe 2-3 times where it’s really impossible to convey to the compiler what I’m trying to do, at least with my knowledge of Rust)