|
|
|
|
|
by smitherfield
3729 days ago
|
|
Thanks for the info, and for the very clear explanation! Obviously, even in C the memory management is a high-level runtime abstraction of sorts (neither the programmer nor the compiler is choosing the actual addresses in memory to alloc/dealloc), so at what point on the continuum of C++-style RAII, Obj-C RC, Swift ARC and so on would you say "garbage collection" comes into play? Is it just one of those "I know it when I see it" type things? |
|
So, one of the reasons this is a bit muddy is that historically speaking, it was much more clear. You had languages which did some kind of "automatic" memory management, if that was through a refcount system of some kind (Like Python was (is?)), or a tracing GC (like Lisp was/is, or Ruby, whatever). And then you had languages which had some sort of "manual" memory management, where you explicitly allocate and free heap memory. I think that the real distinction here is "does runtime state decide if something gets deallocated"? If so, then that's garbage collected. If not, then it's "manual".
But languages like Rust and Swift sort of bend this, and I see them as coming from each side, looking in. So Swift is like a GC'd language that's not _quite_ GC'd, while Rust is like a manually managed language that's not _quite_ manually managed. They feel a bit different.