To me, the main issue with ref-counting isn't "speed", it is "correctness" or "completeness".
Ref-counting cannot cope with cycles in data structures. This can be worked around by contorting your code to work around the issue, but is not what I would call an ideal situation (it creates edge cases that more natural code would be able to cope with), simply to work around limitations in the GC (I will claim it's GC, just not as good as other reachability checkers).
Well, I was replying to AMM optionality, not completeness. Nim has ORC to break cycles - ref ct + cycle checker. I believe Python grew the same thing eventually from similar refcount beginnings. So, completeness worries need not push you away from Nim. As mentioned, there are many options.
These techniques still seem to be called "adjusted/qualified ref counting" rather than "garbage collection". So, I believe terminological problems have muddied the waters yet again. Or else my own incomplete description did { to the extent that differs at all. :-) }
Yeah, once you start talking about "not pure ref counting" (that is, ad din cycle checkers and what have you), the cost of ref-counting goes up dramatically.
I was trying to differentiate between "garbage collection" (the memory management family of techniques) and "specific species of algorithms for GC" (where I would class "pure reference counting" as one, and various augmentations of ref-counting as several more, as well as stop-and-copy, o the easier side).
Costs can go up, but do not always. Nim has some `acyclic` pragmas to help. Answers to almost all performance questions include a "depends", but now we are back on "speed" not completeness. :-) Anyway, you can probably just use `nim c --gc:markAndSweep` to worry less.
At the moment I have no direct intention to use Nim (nor do I have any direct intentions to avoid using Nim). But, it is good to see that mark-and-sweep is a possible GC strategy.
As far as "speed" vs "completeness/correctness" goes, in many (maybe even most) cases, if I have to choose between them, I tend to choose "completeness/correctness".
At work, I changed one of our cluster build pipelines from "fast" to "correct" (making it take about 16x longer to complete). Unfortunately, that was as an action highlighted in a port-mortem as one of the root causes of a cluster completely imploding.
Ref-counting cannot cope with cycles in data structures. This can be worked around by contorting your code to work around the issue, but is not what I would call an ideal situation (it creates edge cases that more natural code would be able to cope with), simply to work around limitations in the GC (I will claim it's GC, just not as good as other reachability checkers).