Inko doesn’t rely on garbage collection to manage memory.
Hmm…
Inko allows multiple borrows (both mutable and immutable borrows), and allows moving of the borrowed values while borrows exist
???!!!
To ensure correctness, Inko maintains a reference count at runtime. This count tracks the amount of ref and mut references that exist for an owned value. If the owned value is dropped but references to it still exist, a panic is produced and the program is aborted, protecting you against use-after-free errors.
Oh. It’s a bit cheeky to do runtime ref counting under the hood and then go and say you don’t rely on garbage collection. It’s not a full tracing garbage collector - it’s worse, it lets you create dangling references and then panics at runtime.
Inko looks interesting, for sure, as a Rust-lite that makes some kinds of code easier to write at the cost of more potential panics (safer, maybe…but desirable?). I’m not sure it’s for me though.
Right, if there was a way to mark them as pure (
const fn?) that would solve it, mostly - as long as upstream crates started annotating their proc macros as such.