Hacker News Reader

Comment by TonyStr | Hacker News Reader

I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management

View on HN

I wouldn't consider Swift manually managed, but also not GC. And not being GC has some practical implications like needing to break cycles yourself, so you need to at least be aware of ownership a little. It's like a manual transmission vs automated manual vs true automatic, AMT removes most of the work but still cannot be treated like full auto.

Good point, I like your formulation

Refcounting is indeed a form of GC (and the languages that want to handle cycles then need an extra form of GC on top of it).

GC specifically means you leave unreferenced mem on the heap until it gets collected in one big sweep later.

You're referring specifically to tracing garbage collection. When a reference count reaches zero, that garbage is collected, often recursively. Among programming language designers, ARC is considered a GC strategy.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

https://users.rust-lang.org/t/reference-counting-garbage-col...

No, I would consider refcounting as variants of GC.

if refcounting is gc, then c++ is a garbage collected language. It has std::shared_ptr

Refcounting isn't GC, but also C++ isn't a refcounted language. You could spam shared_ptr everywhere, but it's not designed for that and probably wouldn't be performant. And because of that, realistically all your libs take raw pointers, so you still have to unwrap your shared_ptrs then be back to managing ownership.

Swift has refcounting built into the language and assumed everywhere. You could always use raw refs in Swift, but that's not the norm.

E.g. in Swift the reference counting is automatic a d implicit

In C++ it is manual and explicit

Reply on news.ycombinator.com