4 ms·
The first bold claim I see on the page is: Deterministic automatic memory management but actually looks like it's neither deterministic (refcounts!) nor actua
by 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 agoThe 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 agoI believe Swift does something similar.
- imtringued 3y agoHow is this worse than C? In C the program.might bit even crash and instead have a remote code execution vulnerability.