←back to thread

Stop making me memorize the borrow checker

(erikmcclure.com)
177 points signa11 | 10 comments | 16 Nov 24 23:29 UTC | HN request time: 0s | source | bottom
Show context
kstrauser ◴[17 Nov 24 00:22 UTC] No.42160831[source]▶
Rust was a pain in the ass until I stopped trying to write C code in it and started writing idiomatic Rust. I don’t know the author of this blog, but he mentions extensive C++ experience which makes me wonder if he’s trying to write C++ in Rust.

Maybe not! Maybe it’s truly just Rust being stubborn and difficult. However, it’s such an easy trap to fall into that I’ve gotta think it’s at least possible.

replies(3): >>42160844 #>>42161027 #>>42161181 #
nicce ◴[17 Nov 24 00:59 UTC] No.42161027[source]▶
I learned Rust before learning C properly.

Oh boy. I see bugs everywhere in C and why the borrow checker exists. It really forces you to understand what happens under the hood.

The most issues in Rust are indeed related the expressions - you don't know how to describe some scenario for compiler well-enough, in order to prove that this is actually possible - and then your program won't compile.

In C, you talk more to the computer with the language syntax, whereas in Rust you talk to the compiler.

replies(3): >>42161173 #>>42161240 #>>42162370 #
1. kanbankaren ◴[17 Nov 24 01:23 UTC] No.42161173[source]▶
> Oh boy. I see bugs everywhere in C and why the borrow checker exists.

Any examples that you could provide? I have been dealing with C/C++ for close to 30 years. Number of times I have shot myself with undefined/unspecified behavior is less than 5.

replies(5): >>42161886 #>>42162308 #>>42162360 #>>42162444 #>>42164671 #
2. dafelst ◴[17 Nov 24 04:05 UTC] No.42161886[source]▶
The borrow checker isn't just about UB, it is mostly about memory safety.

I'm sure you've seen plenty of use-after-frees/use-after-move/dangling pointer type things or null pointer derefs, or data races, etc etc. These are largely impossible to do in safe rust.

3. jjnoakes ◴[17 Nov 24 06:05 UTC] No.42162308[source]▶
The number of times you shot yourself in the foot that you know about. Some of those bullets just haven't landed yet. C and C++ give you very interesting foot-guns: sometimes they go off even when you don't touch them (compiler upgrade, dependencies changing, building on a new architecture, ...)
4. tsimionescu ◴[17 Nov 24 06:24 UTC] No.42162360[source]▶
In 30+ years of experience in C, you haven't used a free()d variable or written past the end of a buffer more than 5 times? If that's true, then you have more care and attention than 99.99% of all C experts.
replies(1): >>42164732 #
5. oneshtein ◴[17 Nov 24 06:53 UTC] No.42162444[source]▶
Borrow checker checks memory safety. Undefined/unspecified behavior still present in Rust[1].

[1]: https://doc.rust-lang.org/reference/behavior-considered-unde...

replies(1): >>42162632 #
6. bombela ◴[17 Nov 24 07:43 UTC] No.42162632[source]▶
Only from code annotated unsafe. In other words, if you do not use the keyword unsafe, you have no undefined behaviors.
7. eddd-ddde ◴[17 Nov 24 15:29 UTC] No.42164671[source]▶
Clearly you must be superhuman then, something as simple as forgetting a null pointer check is bound to hit you every now and then.
replies(1): >>42164757 #
8. kanbankaren ◴[17 Nov 24 15:40 UTC] No.42164732[source]▶
I should have been clear.

Of course, I have done such mistakes, but they were caught early in the dev. process. I am talking about bugs that were caught in production due to misunderstanding of C compilers on 16/32 bit processors.

I also avoid idioms like *p instead write p[i] whereever possible.

9. kanbankaren ◴[17 Nov 24 15:45 UTC] No.42164757[source]▶
Of course, I do, but they are caught early in the dev. process. Not in production though.
replies(1): >>42165006 #
10. kstrauser ◴[17 Nov 24 16:25 UTC] No.42165006{3}[source]▶
I would contend that’s an unusually sophisticated dev process not used by most.