4 ms·

> Inko allows...moving of the borrowed values while borrows exist Yet > With Inko you never again have to worry about NULL pointers, use-after-free errors, un

> Inko allows...moving of the borrowed values while borrows exist Yet > With Inko you never again have to worry about NULL pointers, use-after-free errors, unexpected runtime errors, data races, and other types of errors commonly found in other languages I’m wondering how that can possibly work? Surely the memory safety guarantees are not as strong as Rust’s guarantees.

skavi 3y ago
I assumed reference counting and locking would be employed transparently as needed.
ObscureScience 3y ago
If the moved value still is not allowed to be read or mutated while borrowed elsewere I don't trivially see the issue.
- thatxliner 3y ago
  But how could you statically check that?
  - ObscureScience 3y ago
    I don't see how it would be different if the owner change, as long as the borrow takes precedence.
bradrn 3y ago
It looks like there’s a little information here: https://docs.inko-lang.org/manual/latest/internals/compiler/#ownership https://docs.inko-lang.org/manual/latest/internals/compiler/...
YorickPeterse 3y ago
Inko defaults to heap allocating objects (except for Int, Float, Nil, and Bool), meaning the data pointers point to is in a stable place. Thus, moving them around is just moving a pointer around, not a memcpy of the underlying data. This in turn means it's fine to keep references around. To prevent you from _dropping_ a value while references still exist, Inko uses runtime reference counting. Owned values being moved around incurs no reference counting cost, but creating and dropping references does (just a regular increment for most objects, so pretty cheap). When a value is dropped, the reference count is checked, and if it's _not_ zero a runtime panic is produced, terminating the program. Refer to https://docs.inko-lang.org/manual/latest/getting-started/memory-management/#references-and-borrowing https://docs.inko-lang.org/manual/latest/getting-started/mem... for some additional details. This setup is perfectly memory safe and sound, though in its current form the debugging experience of such errors (although surprisingly rare, but that might just be me) is a bit painful; something I want to improve over time. My long-term vision is to start adding more compile-time checks, such that maybe 80% of the cases where a reference outlives its owned value is detected at compile-time. For the remaining 20% or so, the runtime fallback would be used. In theory this should provide a good balance and only require a fraction of the mental cost associated with Rust. Whether that will work out remains to be seen :)
- tomp 3y ago
  The first bold claim I see on the page is: Deterministic automatic memory management but actually looks like it's neither deterministic (refcounts!) nor actually memory management (deallocating memory can randomly crash the program?! this is even worse than C, where e.g. use after free can crash a program but then you're doing the wrong thing!)
  - YorickPeterse 3y ago
    The reference counts don't dictate when memory is released, that happens when an owned value goes out of scope, just as is the case for Rust. The reference counts are merely used as a form of correctness checking. The result is that allocations, destructors, and deallocations are perfectly deterministic. Deallocating memory itself doesn't crash the program either, rather it's a check performed _before_ doing so (though that's mostly a case of pedantics). This strictly _is_ better than C, because if the program kept running then you'd trigger undefined behaviour and all sorts of nasty things can happen. If you're familiar with Rust, this idea is somewhat similar to Rust's RefCell type, which lets you defer borrow checking to the runtime, at the cost of potentially triggering a panic if you try to mutably borrow the cell's contents when another borrow already exists. You can also find some backstory on the idea Inko uses from this 2006 paper (mirrored by Inko as the original source is no longer available): https://inko-lang.org/papers/ownership.pdf https://inko-lang.org/papers/ownership.pdf
    - silon42 3y ago
      I believe Swift does something similar.
  - imtringued 3y ago
    How is this worse than C? In C the program.might bit even crash and instead have a remote code execution vulnerability.
- insanitybit 3y ago
  > 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?

skavi 3y ago

I assumed reference counting and locking would be employed transparently as needed.

ObscureScience 3y ago

If the moved value still is not allowed to be read or mutated while borrowed elsewere I don't trivially see the issue.

thatxliner 3y ago
But how could you statically check that?
- ObscureScience 3y ago
  I don't see how it would be different if the owner change, as long as the borrow takes precedence.

bradrn 3y ago

It looks like there’s a little information here: https://docs.inko-lang.org/manual/latest/internals/compiler/#ownership https://docs.inko-lang.org/manual/latest/internals/compiler/...

YorickPeterse 3y ago

Inko defaults to heap allocating objects (except for Int, Float, Nil, and Bool), meaning the data pointers point to is in a stable place. Thus, moving them around is just moving a pointer around, not a memcpy of the underlying data. This in turn means it's fine to keep references around. To prevent you from _dropping_ a value while references still exist, Inko uses runtime reference counting. Owned values being moved around incurs no reference counting cost, but creating and dropping references does (just a regular increment for most objects, so pretty cheap). When a value is dropped, the reference count is checked, and if it's _not_ zero a runtime panic is produced, terminating the program. Refer to https://docs.inko-lang.org/manual/latest/getting-started/memory-management/#references-and-borrowing https://docs.inko-lang.org/manual/latest/getting-started/mem... for some additional details. This setup is perfectly memory safe and sound, though in its current form the debugging experience of such errors (although surprisingly rare, but that might just be me) is a bit painful; something I want to improve over time. My long-term vision is to start adding more compile-time checks, such that maybe 80% of the cases where a reference outlives its owned value is detected at compile-time. For the remaining 20% or so, the runtime fallback would be used. In theory this should provide a good balance and only require a fraction of the mental cost associated with Rust. Whether that will work out remains to be seen :)

tomp 3y ago
The first bold claim I see on the page is: Deterministic automatic memory management but actually looks like it's neither deterministic (refcounts!) nor actually memory management (deallocating memory can randomly crash the program?! this is even worse than C, where e.g. use after free can crash a program but then you're doing the wrong thing!)
- YorickPeterse 3y ago
  The reference counts don't dictate when memory is released, that happens when an owned value goes out of scope, just as is the case for Rust. The reference counts are merely used as a form of correctness checking. The result is that allocations, destructors, and deallocations are perfectly deterministic. Deallocating memory itself doesn't crash the program either, rather it's a check performed _before_ doing so (though that's mostly a case of pedantics). This strictly _is_ better than C, because if the program kept running then you'd trigger undefined behaviour and all sorts of nasty things can happen. If you're familiar with Rust, this idea is somewhat similar to Rust's RefCell type, which lets you defer borrow checking to the runtime, at the cost of potentially triggering a panic if you try to mutably borrow the cell's contents when another borrow already exists. You can also find some backstory on the idea Inko uses from this 2006 paper (mirrored by Inko as the original source is no longer available): https://inko-lang.org/papers/ownership.pdf https://inko-lang.org/papers/ownership.pdf
  - silon42 3y ago
    I believe Swift does something similar.
- imtringued 3y ago
  How is this worse than C? In C the program.might bit even crash and instead have a remote code execution vulnerability.
insanitybit 3y ago
> 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?