Comment by pjmlp

2 years ago

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.

  • > 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?

    "Yes" and secondly "no". Here's two different RC algorithms with cycle collection without tracing:

    1. Concurrent Cycle Collection in Reference Counted Systems (Bacon & Rajan. 2001) [1]. Note it has no "global tracing" - which is what's meant by "tracing" in popular usage (right?).

    2. Trial deletion, like as actually usable in Nim with "--gc:orc" [2].

    If the definition of GC encompassing RC has fallen out of favour in popular usage, it's not because of RC having or not having these two particular properties.

    [1]: https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concu...

    [2]: https://nim-works.github.io/nimskull/gc.html

  • Many people also wrongly call themselves "engineers" after a six weeks bootcamp.