[colatkinson]

Reference counting is a type of GC [0]. Just not a very good one in many cases.

I think it's a fair assumption to say that the author is aware of what Arcs are and how they work. I believe their point is more so that because of how async works in Rust, users have to reach for Arc over normal RAII far more often than in sync code. So at a certain point, if you have a program where 90% of objects are refcounted, you might as well use a tracing GC and not have the overhead of many small heap allocations/frees plus atomic ops.

Perhaps there are in fact ways around Arc-ing things for the author's use cases. But in my (limited) experience with Rust async I've definitely run into things like this, and plenty of example code out there seems to do the same thing [1].

For what it's worth, I've definitely wondered whether a real tracing GC (e.g. [2]) could meaningfully speed up many common async applications like HTTP servers. I'd assume that other async use cases like embedded state machines would likely have pretty different performance characteristics, though.

[0] https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

[1] https://tokio.rs/tokio/tutorial/shared-state

[2] https://manishearth.github.io/blog/2015/09/01/designing-a-gc...

[Aurornis]

> I think it's a fair assumption to say that the author is aware of what Arcs are and how they work.

Fair, but when reading an article like this I have to refer to what's written, not what we think the author knew but didn't write.

[astrange]

> Reference counting is a type of GC [0]. Just not a very good one in many cases.

…on a server where you can have a ton of RAM. It's superior on client machines because it's friendlier to swapped out memory, which is why Swift doesn't have a GC.