←back to thread

Stop making me memorize the borrow checker

(erikmcclure.com)
177 points signa11 | 2 comments | 16 Nov 24 23:29 UTC | HN request time: 0s | source
Show context
melvyn2 ◴[17 Nov 24 00:36 UTC] No.42160909[source]▶
The borrow checker exists to force you to learn, rather than to let you skip learning. To make an analogy, I think it would be weird if I complained that I had to "memorize the rules" of the type checker rather than learning how to use types as intended.
replies(3): >>42161088 #>>42161232 #>>42162609 #
Pannoniae ◴[17 Nov 24 01:08 UTC] No.42161088[source]▶
Fair enough, but the problem in this analogy is that this learning isn't always useful or productive in any way. This is more like doing arithmetic in a sort of maths notation where every result must be in base 12 and everything else must be in base 16. Sure, you can memorise the rules and the conversions but you aren't doing much useful with your life at that point.

Obviously, the borrow checker has uses in preventing a certain class of bugs, but it also destroys development velocity. Sometimes it's a good tradeoff (safety-critical systems, embedded, backends, etc.) and sometimes it's a square peg in a round hole (startups and gamedev where fast iteration is essential)

replies(3): >>42161120 #>>42161179 #>>42161194 #
1. Aurornis ◴[17 Nov 24 01:26 UTC] No.42161194[source]▶
Rust shouldn’t “destroy development velocity” once you’ve grasped the core concepts. There is some overhead to being explicit about how things are shared and kept, but that overhead diminishes with time as you internalize the rules.
replies(1): >>42162391 #
2. tsimionescu ◴[17 Nov 24 06:35 UTC] No.42162391[source]▶
Not if you're iterating and have to make fundamental changes. Just like certain advanced type systems, encoding too much at compile time means you have to change a lot of code in unnecessary mechanical ways when the design constraints change, or when you discover them.

This is not a bad thing by the way, it's an extremely plausible design chocie, and is one that Rust made very clearly: rejecting not-entirely-correct programs is more important than running the parts that do work. Languages that want to optimize for prototyping will make the opposite choice, and that's fine too.