4 ms·

> To prevent you from _dropping_ a value while references still exist, Inko uses runtime reference counting. > Inko doesn't rely on garbage collection to manag

> To prevent you from _dropping_ a value while references still exist, Inko uses runtime reference counting. > Inko doesn't rely on garbage collection to manage memory. It sounds like Inko is in fact garbage collected? I have no problem with a refcounted language, it's totally reasonable, but reference counting is garbage collection. Am I misunderstanding something here?

orangea 3y ago
In common usage of the terms, "reference counting" and "garbage collection" are completely different.
- insanitybit 3y ago
  Well, they shouldn't be.
YorickPeterse 3y ago
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 :)
- xigoi 3y ago
  Sounds like the worst of both worlds. You have the overhead of reference counting and you still have to fight a borrow checker?
  - YorickPeterse 3y ago
    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.
- insanitybit 3y ago
  I'm not sure I understand but I'll have to just look into it.
girvo 3y ago
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

orangea 3y ago

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

insanitybit 3y ago
Well, they shouldn't be.

YorickPeterse 3y ago

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 :)

xigoi 3y ago
Sounds like the worst of both worlds. You have the overhead of reference counting and you still have to fight a borrow checker?
- YorickPeterse 3y ago
  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.
insanitybit 3y ago
I'm not sure I understand but I'll have to just look into it.

girvo 3y ago

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