Writing a GC in rust without just dropping the whole business into unsafe is really annoying.
Jason Orendorff has an implementation of a GC in rust called "cell-gc" that seemed like only one I've seen so far that seemed to "get" how to marry rust to the requirements of a GC implementation: https://github.com/jorendorff/cell-gc
Still has a lot of unsafe code and macro helpers, but it's laid out well and documented pretty well. Not sure if you've run across it yet.
Just intuitively, this seems to be using a feature designed to guarantee safety in a way that doesn’t guarantee safety, which raises questions about what the point is.
Author here: to get the compiler to help me as the programmer to produce correct code (not accidentally using handles after GC) without being massively manual, but (at least currently) accepting that it is not a guarantee and thus runtime checks (bounds checks in my case) are needed to retain memory safety.
Just use unsafe then you have all of the good points of rust, like being able to say you wrote it in rust with none of the downsides, like having to write safe code in rust, or that code being slow.
I'm hoping for a future in which humankind looks back with embarrassment at this silly period in its history in which people used to think a leaky and bad abstractions like garbage collection was ever a good approach to deal with resource life-times.
Did you know the Linux kernel has a tracing garbage collector in it, specifically for Unix socket handles? It seems to be a recurring solution to a common problem.
There are lots of suboptimal solutions for lots of problems out there. I don't know why it would matter if the Linux Kernel does the same mistake.
And I'm sure that wasn't the only solution. Just something somebody implemented and noone bothered to change it because it worked "well enough".
But I wouldn't be surprised if this is known to cause the kind of issue GCs are known to cause such as race conditions, resource exhaustion and stalling.
I think we are just used to it. Like we are used to so many suboptimal solutions in our professional and personal lives.
I mean, look something like C++ or the name "std::vector" specifically. There are probably 4 Trillion LoC containing this code out there - in production. I'm used to it, doesn't make it good.
Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?
Some problems are just fundamentally easier to solve using cyclic data structures whose lifetime exceeds the scope where they were created, which would be quite difficult to clean up properly in any other way.
Indeed. I also hope we stop using all of these "high-level" languages. So much overhead just so people don't have to learn how to write proper optimized machine code. It's super-trivial to write a website directly in that too, and it only takes a bit longer, but it is almost twice as fast.
Writing a GC in rust without just dropping the whole business into unsafe is really annoying.
Jason Orendorff has an implementation of a GC in rust called "cell-gc" that seemed like only one I've seen so far that seemed to "get" how to marry rust to the requirements of a GC implementation: https://github.com/jorendorff/cell-gc
Still has a lot of unsafe code and macro helpers, but it's laid out well and documented pretty well. Not sure if you've run across it yet.
Did you notice the https://github.com/kyren/gc-arena mentioned (via Lobsters)?
Compare also 'A Unified Theory of Garbage Collection' https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
This reminds me of the old Monty Python sketch:
https://www.youtube.com/watch?v=uLlv_aZjHXc (Argument Clinic)
No, it doesn't!
Just intuitively, this seems to be using a feature designed to guarantee safety in a way that doesn’t guarantee safety, which raises questions about what the point is.
Author here: to get the compiler to help me as the programmer to produce correct code (not accidentally using handles after GC) without being massively manual, but (at least currently) accepting that it is not a guarantee and thus runtime checks (bounds checks in my case) are needed to retain memory safety.
I clicked on this hoping is was about physical garbage collection
I aim to displease!
Just use unsafe then you have all of the good points of rust, like being able to say you wrote it in rust with none of the downsides, like having to write safe code in rust, or that code being slow.
You can write slow unsafe Rust just fine.
I'm hoping for a future in which humankind looks back with embarrassment at this silly period in its history in which people used to think a leaky and bad abstractions like garbage collection was ever a good approach to deal with resource life-times.
Did you know the Linux kernel has a tracing garbage collector in it, specifically for Unix socket handles? It seems to be a recurring solution to a common problem.
There are lots of suboptimal solutions for lots of problems out there. I don't know why it would matter if the Linux Kernel does the same mistake. And I'm sure that wasn't the only solution. Just something somebody implemented and noone bothered to change it because it worked "well enough". But I wouldn't be surprised if this is known to cause the kind of issue GCs are known to cause such as race conditions, resource exhaustion and stalling.
Let me do some quick research:
https://gist.github.com/bobrik/82e5722261920c9f23d9402b88a0b... https://nvd.nist.gov/vuln/detail/cve-2024-26923
Still the whole world runs on GC-ed languages so it must be an abstraction at least some people like to work with.
And I'm pretty sure using a GC in some cases it's the only option to not go crazy.
I think we are just used to it. Like we are used to so many suboptimal solutions in our professional and personal lives.
I mean, look something like C++ or the name "std::vector" specifically. There are probably 4 Trillion LoC containing this code out there - in production. I'm used to it, doesn't make it good.
Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?
Well, to be fair, RAII is a leaky abstraction. For example, if your programme crashes there's no guarantee that you'll ever give the resources back.
See https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
> See https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
This example is specific to C++
> (..) if your programme crashes there's no guarantee that you'll ever give the resources back.
What guarantees can you have from a "crashing program", and by what definition of crashing?
> RAII is a leaky abstraction
Any abstraction is leaky if you look close enough.
> What guarantees can you have from a "crashing program", and by what definition of crashing?
You might like https://www.usenix.org/conference/hotos-ix/crash-only-softwa...
Some problems are just fundamentally easier to solve using cyclic data structures whose lifetime exceeds the scope where they were created, which would be quite difficult to clean up properly in any other way.
Indeed. I also hope we stop using all of these "high-level" languages. So much overhead just so people don't have to learn how to write proper optimized machine code. It's super-trivial to write a website directly in that too, and it only takes a bit longer, but it is almost twice as fast.
I'm a big fan of high-level languages and abstractions. I'm just not a fan of bad abstractions.