Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Not really the point of the post, but there is a third memory allocation paradigm where you can do manual allocations and deallocations, but without the mental overhead of having to remember to free memory because the compiler will force you to properly handle it. Mojo has linear type support so you can do something like this: https://x.com/melodyogonna/status/2085089269484343725?s=20by melodyogonna
- This is one of the best high-level survey explanations of GC I have seen, nice work.by pclowes
- I rarely see a real use case bottle necked on garbage collection.
- > In Rust you pay for it by arranging your program in a way the compiler can verify.
I disagree with this. The sentence implies that this work is done in order to make the compiler happy, where my experience is that it forces the programmer to actually get it right.
I had an "aha moment" when I was frustrated at failing to express my intent to the compiler, and suddenly realised that the reason I couldn't "just say the magic words" was that my object ownership design was inherently flawed. I had to make large changes not to make the compiler happy, but to actually have a coherent design.
So no, it's not about what "the compiler can verify". That's like saying "my lawyer won't let me do this". No, your lawyer is your employee, not your boss. They're just saying that if you do this, then you may go to prison. It's not the same thing.
("unsafe" is the Rust way to go "thank you, legal department, but I'm making a business decision to take this risk. Your concern has been noted")
- > I disagree with this. The sentence implies that this work is done in order to make the compiler happy, where my experience is that it forces the programmer to actually get it right.
Haskellers say the exact same thing. :P Personally, I'd much rather get shit done and don't appreciate tools "forcing" me.
by bjourne - I've had that moment in Rust too, where there was no composition that effected what I wanted, because supporting that model would have meant a very different backing data structure. However in that case I actually didn't care about the kind of correctness problem it was saving me from.
I've also had the converse experience, where I know full well that the structure I'm trying to impose is correct and quite efficient, but its part of the space that rust doesn't cover.
Rust is great. It's a noble attempt to bring a degree of correctness to a problem space that suffers from a great deal of slop. But to pretend that the model is complete, or that the design decisions that were made are perfect in every way, is just wrong. That the rust compiler and runtime can't support my construct isn't really an absolute value judgement on that idea in the first place. The rust compiler isn't really an oracle that tells you whether something is right or not in an arbitrary value system.
by convolvatron - I understand what you’re saying, but I read that phrase in a different way.
Let’s say you have two ways of doing the same thing: both work, both are legit and neither introduce GC bugs. The only difference between the two is that one can be verified by the compiler while the other can’t, so you are stuck with solution no. 1 although both would work.
To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler?
I’m not implying that’s the case, but that’s what I feel the author is saying.
by ron_k - There's a third way here. It could be called many things: Single ownership by default, automatic stack lifetimes, hidden unique pointers, etc. The main idea is that the lifetime of dynamic heap data is treated no differently to primitive stack data: Clean it when it goes out of scope. Rust and C++ require you to specify this manually, but Nim is unique among native-compiled languages in that is does it by default, with tools to opt-out. An advantage of this approach is that combining immutable values and static analysis can reduce most parameter passing to borrows, again, without needing the programmer to specify, by default. The main cost being that some assignments, especially crossing the variable-to-immutable line or vice-versa, would require a copy.by netbioserror
- What does GC cost? For Caddy with an incredibly synthetic http only benchmark it costs about 2ms of latency and somewhat less throughput. Worth it in an incredibly artificial benchmark? Perhaps. However when it comes to real world usage the cost is a significantly smaller piece of the pie.
- I used to write a lot of Javascript-like Extendscript scripts back when I was using InDesign a lot. The DOM's global object $ had a method to directly invoke the garbage collector. It made a difference certainly, but it was difficult to tell to what extent because InDesign itself gradually leaks memory and becomes more bloated the longer you use it in a single session.by 220hertz
- Props for using a correct nomenclature. Reference counting is a "kind of automatic garbage collection. Tracing garbage collection is also a kind of automatic garbage collection.by bjourne
- Agreed, for most real world softwares, the cost of GC is irrelevant. But there are still some programs like databases or game engines where the cost can start adding up. That's when you measure and optimize.by shivanshuag
- > That's when you measure and optimize.
How do you "optimize" the GC away after you wrote your entire database server in a language that uses it?
by marcosdumay - This assumes that you’re only ever running a single software at a time. Sure, 2-10x slower/memory consumption might not matter in a vacuum, but when every software is like this, you get machines that feel slower than they did 2 decades ago.by slopinthebag
- Yet the three major game engines Unreal, Unity and Godot all have a GC on their infrastructure, and Capcom is quite happy with their .NET fork on RE Engine.
Also every single graphics application that uses Metal or DirectX, relies on reference counting as GC algorithm.
by pjmlp - Did you "Agreed" your own blog?by jayd16
- Careful, this statement is misleading:
> The leaks that come from forgetting to free something go away entirely.
Not quite: In manually-managed and referenced counted languages with destructors, releasing resources, (open file handle, open socket, open connection to a database, ect,) happens when objects are cleaned up.
In a (tracing) garbage collected language, releasing resources is a very manual process. You might not have a memory leak, but leaking file handles or similar resources is a real problem with real consequence.
by gwbas1c - Even things built directly on underlying malloc and free typically have some form of "garbage collection" in the malloc implementation for efficiency and performance (geometric sizing, thread caching, etc).
It's best to think about lifetimes and lifecycles where possible. Immutability where sensible and things like pool allocation are examples of this.
GC languages can result in quite pessimistic code because they encourage people to NOT think about what is going on. But people have also built functional HFT engines on things like the JVM by thinking about lifetimes and lifecycles.
by kev009 - Ultimately, the entire problem of deallocation in general is a continuum, not a binary, and I tend to find it hard to take anyone seriously who is vigorously arguing about how awful GC is if they don't understand that and indicate some understanding of the concept. The closest you can get to real "manual" memory management on a modern system is to use nothing but arena allocations, and if you really want "manual" memory management, you need to allocate some small fixed number of arenas, because if you're constantly allocating and deallocating them that is itself probably an automated process that could go wrong, at least in theory. Malloc/free or new/delete isn't really "manual memory management".
The wide variety of options and tradeoffs, with fewer clear lines in the sand than most people seem to think, is already enough to call it a "continuum" but what really finishes the job is that they're all mixable and matchable. Something like Zig makes that really obvious, but most static languages have at least some sort of ability to mix in multiple strategies. There's nothing wrong with a C++ program that uses new & delete, and also uses arenas for some things, and also uses garbage collection for some things, and also has an integrated scripting language like Lua with its own memory strategies. Such programs are not that uncommon... that describes modern games nowadays, the supposed canonical case where you "can't afford GC". But it can... it just fences it in to a particular domain where it fits.
by jerf - > Think of a service that keeps a large cache in memory, or an index built out of millions of small objects that all point at each other. Every one of those pointers has to be followed on every cycle, for as long as the process is up.
That's a strange thing to assert, having acknowledged the existence of generational GC.
by kazinator - It occurs to me that I have never seen any description of generational GC that actually notes how that works, though.
If we have two generations, young and old, we obviously can't simply "just collect in the young generation" — which I feel like is exactly what most generational GC descriptions say. If we only traced young objects, we could very well miss an old object pointing at a young one, collect the younger object, and now we've got a dangling pointer.
So there must be some book-keeping to avoid tracing everything (or what'd be the point of generations), but I have no idea of what that book-keeping is, or its cost.
> Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.
by deathanatos - A generational GC might help with some part of the problem but does not solve it entirely. Major collection still happen which will scan everything, just with a reduced frequency. Long libed caches might still have pointers being mutated frequently (like an LRU cache), which will put objects in younger generation. Golang does not have a generational GC. There are examples where long lived caches have been a problem in golang. One example - https://discord.com/blog/why-discord-is-switching-from-go-to...by shivanshuag
- Similarly, the statement
> Reference counting also has its own running cost, paid on every copy of a pointer you make and every time you drop one.
isn’t 100% true. It’s not necessarily on every copy or drop. Compilers can (and do) elide reference count updates if they can proof they aren’t needed, and can even skip allocating room for reference counts if they can proof it isn’t needed (example: a local object that doesn’t escape its scope)
I also find it a miss that the article doesn’t discuss memory usage. A garbage-collected program needs more memory to match the performance of the equivalent manually managed language.
https://dl.acm.org/doi/10.1145/1094811.1094836 says you need to give it 5 times the memory, but that’s from 2005 and likely outdated.
by Someone