4 ms·
I'm happy to see this article, it does look like a much clearer explanation of Hare's pros and cons in terms of safety. I might not agree to every point but ack
by lifthrasiir 4y ago
I'm happy to see this article, it does look like a much clearer explanation of Hare's pros and cons in terms of safety. I might not agree to every point but acknowledging and documenting trade-offs is surely a big plus.
On borrow checkers: There is a big dichitomy between type systems and static analyses, where type systems aim to be sound---never fails to catch certain bugs, at expense of false positives---while static analyses tend not. But Rust's borrow checker is a sound static analysis combined with a type system. In fact it is a kind of optimal design when you are only allowed to add additional kind of types, and this restriction made the borrow checker a very impressive achievement. But there are other possibilities if you loosen a bit---either slightly unsound analysis [1] or annotation methods other than types. I believe Hare should better explore those possibilities instead of having a borrow checker.
[1] In fact Rust has already compromised as well; for example its notion of memory safety doesn't ensure no memory leak. It is still unlikely but not impossible to unintentionally leak memory, so it is deemed acceptable. You can use a similar compromise in Hare.
- tialaramex 4y agoThe existence of features like Box::leak() doesn't compromise Rust's memory safety which is why that's not marked unsafe. The reference counted and garbage collected languages likewise can leak, and if Box::leak() didn't exist, people would just roll their own by the same means. It's not even as though their hand-rolled mechanism would be syntactically heavier, you can't thing.leak() because leak intentionally isn't a method, it's just an associated function on Box and so you will need to explicitly Box::leak(thing) I don't think Hare's design is at all conducive to trying to retrofit a borrow checker, and so I would agree with you that it should not attempt such a thing.
- lifthrasiir 4y agoI mean, the memory safety is not an exactly defined term and it took a compromise to pick the exact definition of memory safety for Rust. I fully agree that the memory leak is far less risky than this notion of memory safety, but it is still a (slight) compromise especially when you are new to Rust. As a new language Hare doesn't have to take this granted.