Live data from Hacker News

Garbage collection is contrarian

trynova.dev

11–20 of 25 posts

Re: Garbage collection is contrarian

#11
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.

Re: Garbage collection is contrarian

#12

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.

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.

Re: Garbage collection is contrarian

#13

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.

Re: Garbage collection is contrarian

#14
post #13

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

Re: Garbage collection is contrarian

#15
post #12

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.

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.

Re: Garbage collection is contrarian

#16

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.

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...?

Re: Garbage collection is contrarian

#18

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 pre…

Did you notice the https://github.com/kyren/gc-arena mentioned (via Lobsters)?

Re: Garbage collection is contrarian

#19
post #4

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.

Re: Garbage collection is contrarian

#20

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.

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 co…

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...

Post reply on HN