[illuminator83]

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.

[aziis98]

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.

[illuminator83]

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.

[aapoalas]

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

[eru]

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

[ameixaseca]

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

[eru]

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

[zahlman]

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.

[AllegedAlec]

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.

[illuminator83]

I'm a big fan of high-level languages and abstractions. I'm just not a fan of bad abstractions.

[immibis]

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.

[illuminator83]

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