Hacker News Reader

Comment by bad_user | Hacker News Reader

> first language to bring non-GC automatic memory management to the mainstream ... Other languages in this space include Swift

Ugh, “Arc”, aka (automatic) reference counting, is an implementation of GC as well. It may have certain characteristics, like having worse throughput, corner cases, and better predictability/latency characteristics, but it's GC nonetheless. That's not manual memory management. Swift is not a non-GC language.

And that's the big issue that people are missing — Rust tackles some hard problems regarding memory management, and a friendlier alternative exists: garbage collection.

View on HN

Both ARC and garbage collection are memory management techniques. ARC does not equal garbage collection though. Garbage collection runs at intervals and is triggered by certain signals (memory pressure, etc), pauses all threads and scans for objects that can be deallocated. It is a very different concept than ARC.

https://courses.cs.washington.edu/courses/cse590p/05au/p50-b...

This paper makes a strong argument that “pure” tracing garbage collection and “rote” reference counting are effectively duals at the opposite ends of a spectrum of implementation choices.

For example, GC’s often optimize differently for young vs. old objects. How do they distinguish these? By “counting” (one bit) their references across one or more traces in a series of sweeps.

And a hot wheels car is a car, but I would be perplexed to see one offered to me at a car dealership

ARC is a method of implementing garbage collection, and is discussed as such in academic literature.

What you are equating with "garbage collection" is Mark-Sweep, which is an another way to implement GC, with a very different set of tradeoffs. (Broadly, better throughput at the expense of higher latency.)

In common usage everyone understands that GC = tracing GC.

Deleting large hierarchy of objects when the last reference gets decremented also is triggered by a certain signal (reference decrement) and pauses all threads while it collects garbage. There are even tunable GC that become ARC if you set particular parameter to "N=1"

> There are even tunable GC that become ARC if you set particular parameter to "N=1"

You can call a pointer to a value a "one-element static array."

I'm not sure that collecting a large hierarchy of objects requires pausing all threads. What can definitely require pausing threads (other than in specialized concurrent collectors) is the tracing step, which relies on some invariants that in simple GC implementations (not the more specialized concurrent ones mentioned earlier) are only ensured at very specific points in the program (known as GC "safepoints").

My bad, thanks for correcting! Of course single thread freeing a lot of heap allocations will not pause other threads by itsel. What I had to write was: calling destructor of an object that in turn calls destructors of other objects (because a large tree of reference counted objects loses last reference to it's root) stops that thread, until all deallocation is done.

It's not "automatic" reference counting, it's "atomic" reference counting. And it's not automatic, it's entirely manual and implemented with traits as a fat pointer. Reference counting types in Rust are just defaults that give certain guarantees.

This feels like people arguing that atheism is a kind of religion. Borrow checking and a library of safe default primitives make it so you don't really have to think about memory management; except to the extent that you generally stick to those primitives, and that you have to install the borrow checker into your own head to write Rust comfortably (although the compiler will help.)

Rust doesn't have any garbage collection, but it can just assume how you would want to deal with memory by forcing you to be very specific about when values should be created or destroyed.

In the context of Swift, ARC is automatic reference counting: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Reply on news.ycombinator.com