Comment by pjmlp
2 years ago
Reference counting is also a GC algorithm, even though people pretend otherwise, as they seldom learn from CS literature.
Plus all systems languages with GC, including C#, can do C and C++ style memory management.
2 years ago
Reference counting is also a GC algorithm, even though people pretend otherwise, as they seldom learn from CS literature.
Plus all systems languages with GC, including C#, can do C and C++ style memory management.
This is an old argument, and it’s well understood that “GC” by default refers to tracing GC and delayed collection. (Without delayed collection, there arguably isn’t any “garbage” in the first place.)
“Can do C++ style memory management” is very different from what happens when coding in the default idiomatic style of the language and when using existing libraries written in the language. What happens by default is a relevant consideration.
Understood as such by those that don't grok CS.
What is relevant is if one is actually skilled in using their tools, or should be doing something else instead.
A definition can’t be right or wrong, it can only be popular or unpopular.
The definition of GC encompassing RC has fallen out of favour because it doesn’t capture the essential distinctions that people want to make: firstly, are cycles broken automatically? secondly, is there any tracing process happening behind the scenes?
Most people are happy to accept that CPython is GC because it does RC and cycle collection so you are managing memory thinking about paths from a root, but not Swift because you are managing memory thinking about an ownership graph.
In the past, people wanted to make a different distinction: is the CPU having to do extra work to keep track of a reference count. When CPUs were slow, this was an important distinction to make. Nowadays it’s a less important distinction so the definition has evolved.
2 replies →