←back to thread

Stop making me memorize the borrow checker

(erikmcclure.com)
177 points signa11 | 3 comments | 16 Nov 24 23:29 UTC | HN request time: 0.606s | source
Show context
troad ◴[17 Nov 24 01:04 UTC] No.42161064[source]▶
I think it's telling that whenever someone raises concerns about any element of Rust, no matter how constructively, they're always met with a wall of "you must not truly get the borrow checker," or "you're using Rust wrong," or "stop trying to write <C/C++/Java/etc> in Rust!", usually with zero evidence that that is in fact what is happening. There's never anything to improve on Rust, it's always user error / a skill issue. If there ever surfaces any audio of Linus Torvalds and Ken Thompson discussing the pros and cons of the borrow checker, I expect a sea of patronising anime avatars to show up, seeking to explain Rust's invention of the concept of ownership to them.

Rust is really nifty, but there are still (many) things that could be improved in Rust, and we'd all benefit from more competition in this space, including Rust! This is not a zero sum game.

Honestly, I also think many people just want a nice ML-like with a good packaging story, and just put up with the borrow checker to get friendly C-like syntax for the Option monad, sum types with exhaustive matching, etc. This is a use case that could very much benefit from a competitor with a more conventional memory model.

replies(7): >>42161186 #>>42161243 #>>42161255 #>>42162270 #>>42162593 #>>42162641 #>>42162713 #
1. chipdart ◴[17 Nov 24 07:47 UTC] No.42162641[source]▶
> I think it's telling that whenever someone raises concerns about any element of Rust, no matter how constructively (...)

I'm far from a Rust expert, but to me if someone is whining about how it is hard to track lifecycle rules of an object because they are passing it through long chains of function calls across all sorts of boundaries, what this tells me is that you're creating your own problems that you could avoid if you simply passed the object by value instead of by reference. I mean, if tracking life cycles is a problem then why not prevent it from being a problem? Not all code lives in the hot path. I'm sure your performance benchmarks can spare a copy somewhere.

replies(1): >>42163643 #
2. brabel ◴[17 Nov 24 11:47 UTC] No.42163643[source]▶
> I mean, if tracking life cycles is a problem then why not prevent it from being a problem?

So you're suggesting that people should just wrap everything in Arc or make copies everywhere to avoid lifetimes? At that point why not just use Java/OCaml/Swift/your-favourite-GC-lang?

replies(1): >>42164417 #
3. chipdart ◴[17 Nov 24 14:42 UTC] No.42164417[source]▶
> So you're suggesting that people should just wrap everything in Arc (...)

You're the only one who managed to come up with this nonsense. No one else did, and clearly you did not pick that from what I wrote because I definitely did no wrote that.

Please refrain from slippery slope fallacies.