[simias]

Meh. I might have a huge Stockholm syndrome with manual resource management since I've basically started coding with C and used GC-free languages for most of my life since them but I never really understood why people liked GCs so much outside of scripting languages where convenience trumps correctness and you just litter your resources around instead of tracking them properly.

Are people using GC languages really often thinking "uh, I don't know when I won't be needing this resource anymore, thankfully the GC will figure that out for me"? Because I certainly never do. Either the resource is scoped and I expect it to be destroyed at the end of a certain block RAII-style, or it's some longer-lived resource (connection handle, object in a videogame, Window object in a GUI) that I'm going to store in some container and destroy when I no longer need it. If I have multiple references and a complex dependency graph I might use a reference counted container which is effectively a very simplistic GC but it's the exception and not the rule and it's still completely transparent and easy to reason about.

I never, ever, feel like I'm missing a GC when I'm coding in Rust or C++. In C I miss destructors and RAII but that's it. I just don't understand why they're so popular, at best they save you a few lines of cleanup code in your destructors, at worse they make your code behave sub-optimally and non-deterministically because you don't know when your objects are going to be destroyed and your destructors are going to run. Then if you need to write critical code you have to carefully step around the GC to be sure that your perf will be deterministic.

I genuinely don't get GCs.

[kjeetgill]

From a Java programmer's perspective: I agree that a majority of your could would function just as well with RAII-style deallocations. That said, it's not too rare to throw objects around in queues or hashmaps and the garbage collector can save you from sloppy code turning into memory leaks.

Also consider, GC can "solve" a number of other issues. malloc() and free() aren't always cheap to do in the critical path especially when you have heap fragmentation. There are solutions without GCs, but compacting generational GCs combat both of these things without requiring you to even be aware of them. I'm not claiming they're always the best solutions but hopefully I've explained their motivations.

[PopsiclePete]

I'm guessing you've never written heavily concurrent code.

C/C++/Rust are totally fine when you have a single thread. It's concurrency and parallelism where object ownership and who gets to destroy what and when becomes a real problem unless you have GC.

[simias]

> I'm guessing you've never written heavily concurrent code.

Guess again.

> C/C++/Rust are totally fine when you have a single thread. It's concurrency and parallelism where object ownership and who gets to destroy what and when becomes a real problem unless you have GC.

Given that one of Rust's main shticks is concurrency and parallelism it's an odd thing to say. You can always use an Arc<> if you want reference counting between threads which is sort-of GC but opt-in and perfectly deterministic.