https://www.ptc.com/en/products/developer-tools/perc
We have already have had enough from anti-GC cargo cult from "manual memory management is great" folks.
Having a GC (which RC is also an algorithm subset), doesn't preclude having other features.
https://www.ptc.com/en/products/developer-tools/perc
We have already have had enough from anti-GC cargo cult from "manual memory management is great" folks.
Having a GC (which RC is also an algorithm subset), doesn't preclude having other features.
I agree that a GC can be a viable implementation of memory management though.
Which I would refer as compiler assisted, although not really a proper term.
There is a reason outside Rust, everyone else is string to combine GC alongside affine/linear/effects/dependent types instead of one solution for everything.
The productivity of having a GC, with the type system capabilities to go lower level, when the profiler says so.
Although I have to conceded, Rust made a great job bringing ATS and Cyclone ideas into mainstream.
Additionally with AI powered languages, naturally most of this will be automated anyway.
But yes, I was also thinking about the borrow checker.
Not necessarily in Rust, as other languages start to adopt similar techniques.
Even the dragon book refers to ref counting as a form of garbage collection.
Line 2 of Ref counting's Wikipedia page refers to garbage collection.
People have argued since the invention in 1960, but... Ref counting is one form of GC. [0] It might not be a tracing GC, but it is GC.
The other languages adopting such type systems, also keep automatic resource management around for productivity.
The ones that don't, are still in the looking for meaningful adoption stage.
As a general rule, tracing seeks to optimise for throughput while refcounting seeks to optimise for footprint, although the two can become more elaborate and converge (as shown in the paper I linked).