Garbage collectors are actually pretty dang clever. I always thought they are inferior but honestly they can be really fast and the ergonomic benefit you get from them is just priceless

One really cool trick of multi generational GCs is having a young generation where all new objects are allocated and on each GC cycle you fully clean it out by deleting dead objects and promoting living objects to a higher gen

This way you can just linear allocate new objects in the young gen which is magnitudes faster than a general purpose allocation algorithm

You can basically heap allocate for almost free! Bunch of short lived temporary strings? No problem!

Yes, they are ok. They perform worst when you constantly create and delete new objects, like a naive particle system or potentially badly implemented user sessions. In general if you use pools for your objects then GCs don't get in the way too much. A great example of when they do is the oroginal Minecraft. Hundreds of voxels constantly changed over, though can be easily optimized with better initialization algos... That being said, once you start managing your own inits and pools you actually stop needing GCs in the first place, because you're unlikely to leak memory once you're good at managing it.

So in short, they are not the worst thing ever, but they become peformance hogs if you don't know what you're doing, and the more you know the less you need them. So they are pretty great for medior devs that are pretty good themselves but don't understand or don't want to deal with memory management

I for one really like managing my own memory, because you can do constant time access for most things and align things in memory besed on usage, even put them close to each other if they are often accessed together so pre-fetching can take effect. It's small things but they can add up and most of all It's fun to optimize the shit out of simple stuff. Particularly fun when writting crackers or generators that benefit from every cycle you can squeeze out. GCs can be a big enemy of those

@Hazarth Especially for realtime code (games) they can kinda suck. But even then, modern gcs like Java's shenandoah can do half a millisecond pauses regardless of heap size!

Your dismissal is kinda exactly what I'm talking about though. I've used to think the same, but now I realize that's actually wrong. GCs rule! (when they make sense)

@Hazarth The problem isn't managing your own memory, it's reference cycles. Being able to have references up and down can really simplify code

I mainly use Rust and for game dev not being able to hold references to everything can be very annoying

@12bitfloat you can't do that because of Rust? I'm sure it's possible to write some generic wrapper around it that you can always use to work around certain behavior. Maybe lorentz knows.

One drawback is memory fragmentation. Meaning you will not be able to use all the preallocated memory [assuming gc does preallocation, like in jvm]

another major drawback -- STW phases for full cleanup [again, assuming hotspot-jvm-like gc]

@retoor Well you can with Arc but then you can get memory leaks if you have cycles. To prevent that you have to manually use Weak references but those are kinda annoying in some circumstances. e.g. a framebuffer with child images should both keep eachother alive no matter which object you hold but that's not possible without tracing (like a gc would)

@netikras Pause times should be effectively irrelevant as of a few years ago with shenandoah gc

Fragmentation is a good point, although a vm could be (and maybe sometimes is?) better since it can move objects around unlike a lower level lang

@12bitfloat and a VM is kinda an Arena on its own I guess.