The reference counts are used to prevent dropping a value that still has references to it, but it doesn't dictate _when_ that drop takes place. Instead, an owned value is dropped as soon as it goes out of scope, just like Rust.

So no, Inko isn't garbage collected :)

Sounds like the worst of both worlds. You have the overhead of reference counting and you still have to fight a borrow checker?

The cost of reference counting is only present when creating and destroying aliases, moving moved values around incurs no cost. That alone significantly reduces the overhead.

In addition, for objects other than String, Channel and processes, the count is just a regular increment (i.e. `count += 1`), not an atomic increment.

It's true that this can have an impact on caches, as the count increment is a write to the object, and so over time I hope to add optimizations to remove redundant increments whenever possible.

As for the borrow checker: Inko doesn't have one, at least not like Rust (i.e it's perfectly fine to both mutably and immutably borrow a value at the same time), so the cost of that isn't present.

I'm not sure I understand but I'll have to just look into it.

Colloquially, "garbage collection" typically refers to non-deterministic automatic memory management (and/or stop-the-world), whereas ref-counting is typically considered deterministic

Not really correct in an academic sense, but this isn't the only language I've seen talk about ref-counting as something other than garbage collection

In common usage of the terms, "reference counting" and "garbage collection" are completely different.

Well, they shouldn't be.