4 ms·
> What in particular do you find cumbersome about the borrow system? The refusal to accept code that the developer knows is correct, simply because it does not
by rc00 1y ago
> What in particular do you find cumbersome about the borrow system?
The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.")
When the purpose of writing code is to solve a problem and not engage in some pedantic or academic exercise, there are much better tools for the job. There are also times when memory safety is not a paramount concern. That makes the overhead of Rust not only unnecessary but also unwelcome.
- the__alchemist 1y agoThank you for the answer! Do you have an example? I'm having a fish-doesn't-know-water problem.
- int_19h 1y agoBasically anything that involves objects mutually referencing each other.
- the__alchemist 1y agoOh, that does sound tough in rust! I'm not even sure how to approach it; good to know it's a useful pattern in other langs.
- int_19h 1y agoWell, one can always write unsafe Rust. Although the more usual pattern here is to ditch pointers and instead have a giant array of objects referring to each other via indices into said array. But this is effectively working around the borrow checker - those indices are semantically unchecked references, and although out-of-bounds checks will prevent memory corruption, it is possible to store index to some object only for that object to be replaced with something else entirely later.
- estebank 1y ago> it is possible to store index to some object only for that object to be replaced with something else entirely later. That's what generational arenas are for, at the cost of having to check for index validity on every access. But that cost is only in comparison to "keep a pointer in a field" with no additional logic, which is bug-prone.
- Cloudef 1y ago>unsafe rust Which is worse than C
- Ygg2 1y ago> The refusal to accept code that the developer knows is correct, How do you know it is correct? Did you prove it with pre-condition, invariants and post-condition? Or did you assume based on prior experience.
- yohannesk 1y agoWriting correct code did not start after the introduction of the rust programming language
- Ygg2 1y agoNope, but claims of knowing to write correct code (especially C code) without borrow checker sure did spike with its introduction. Hence, my question. How do you know you haven't been writing unsafe code for years, when C unsafe guidelines have like 200 entries[1]. [1]https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definit... (Annex J.2 page 490)
- int_19h 1y agoIt's not difficult to write a provably correct implementation of doubly linked list in C, but it is very painful to do in Rust because the borrow checker really hates this kind of mutually referential objects.
- Ygg2 1y agoHard part of writing actually provable code isn't the code. It's the proof. What are invariants of double linked list that guarantee safety? Writing provable anything is hard because it forces you to think carefully about that. You can no longer reason by going into flow mode, letting fast and incorrect part of the brain take over.
- edflsafoiewq 1y agoOne example is a function call that doesn't compile, but will if you inline the function body. Compilation is prevented only by the insufficient expressiveness of the function signature.
- charlotte-fyi 1y agoIsn't the persistent failure of developers to "know" that their code is correct the entire point? Unless you have mechanical proof, in the aggregate and working on any project of non-trivial size "knowing" is really just "assuming." This isn't academic or pedantic, it's a basic epistemological claim with regard to what writing software actually looks like in practice. You, in fact, do not know, and your insistence that you do is precisely the reason that you are at greater risk of creating memory safety vulnerabilities.