| 20 Mar 2026 |
 piegames | But also, having to write a custom GC isn't too bad if one has sufficient freedom in the design constraints | 12:08:27 |
| piegames | Things like "we only have 4 types which need GC", "doesn't have to be super fast", "Values are opaque pointers anyways because of pointer tagging" do make it less horrible | 12:10:21 |
 emily | those aren't the hard parts | 12:10:35 |
| emily | it's stack rooting, esp if you want a sound + precise Rust API (cf. https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/) | 12:11:27 |
| emily | (let alone ergonomic 😅) | 12:11:34 |
| emily | though refcounting with cycle collection is relatively simpler (but not sure if the perf would be appealing compared to Boehm for a language like Nix that has tons of cycles...) | 12:12:33 |
| piegames | horrors say refcounting will be too slow | 12:13:00 |
| piegames | but it might still be a viable intermediate approach to get some Rust GC experience | 12:13:16 |
| piegames | or rather, there's a good crate which does this, so might just use that for a start | 12:13:29 |
| emily | refcounting + cycle collection basically punts on the hard parts about rooting, so doesn't make sense to switch to if you'll need to adjust all your code to handle the real thing later | 12:15:19 |
| emily | (allocator API not being stable and probably never going to be doesn't help either, although indeed mitigated by having a limited collection of things that need GCing) | 12:15:37 |
| emily | (I wouldn't be surprised if there are some surprisingly entangled object lifetimes between Nix and non-Nix though) | 12:16:21 |
 Qyriad |
|
