Live data from Hacker News

Ask HN: How do I understand Rust?

news.ycombinator.com

1–10 of 61 posts

Ask HN: How do I understand Rust?

#1
Serious question. I've been trying to learn Rust for a month now and I keep end up fighting the compiler with borrowing errors.

I'm really not sure where to turn for help. It seems like everything I know about structuring a program goes out the window when borrowing comes into the picture.

Thanks.

Re: Ask HN: How do I understand Rust?

#3
I've been doing software dev since I was a kid. In my mid-30s now. I spent almost a month with Rust about a year ago. I was very disappointed. The borrowing rules seem to have changed as the language had evolved. I found the Internet documentation to be very confusing. My conclusion was to let Rust be. It felt like coding with restraints, and as my Rust expert friends tell me, that is the way it is supposed to be. My friends write kernel modules, do low level systems etc. where they know exactly what they are doing. I mostly do exploratory programming. I think Go, Elixir and Python are the best languages for the kind of stuff I'm interested in.

Re: Ask HN: How do I understand Rust?

#4
Well, I think a couple of points:

1. An outline of the problem you're trying to solve helps 2. You should really stop by the #rust-beginners channel on IRC. Everyone is super friendly

Glad to see that you're trying Rust, and if I'm there when you stop by - glad to help if I can!

Re: Ask HN: How do I understand Rust?

#5
It is likely that your structure is in fact allowing _potential_ errors to enter into the picture. Most of the time in C or C++ you would ignore them since it is obvious to you where things will be owned and not owned as the program progresses, but the compiler is must more strict and it will not allow any potential errors to exist. I don't think you will find a shortcut around identifying those areas until you work through them a bit.

The other big thing that I wrestled with was my idea of in place mutation of data, and how much rust hates that. It took a while for me not to feel so bad about making a local variable to maintain ownership of some memory and "moving" it in and out of some parent structure. While it might look bad, there is a deal of trust you need to have with the compiler that it will in fact optimize out those move, and your main goal is to make sure ownership is explicit.

Re: Ask HN: How do I understand Rust?

#6
> It seems like everything I know about structuring a program goes out the window when borrowing comes into the picture.

Try to avoid structured programming and mutable state where possible. Apply functional programming idioms and use immutable data structures if you can. Rust adopts many features from functional programming languages: http://science.raphael.poss.name/rust-for-functional-program...

Borrow checker will interfere only when you are trying to manage mutable state that is hard to reason about. If you absolutely must keep some mutable data structure around, you can fall back to unsafe code. There is nothing wrong with it, but make sure to put all unsafe code into separate module and provide only safe interface, that is absolutely unbreakable no matter how you use its public API.

Make sure you know about this module: https://doc.rust-lang.org/std/mem/ It is nearly impossible to create complex data structures without it, even linked list implementation requires it. Learn to use replace, swap and .take(). These functions provide great example of a safe API for unsafe operations.

Re: Ask HN: How do I understand Rust?

#7
It really depends on what you are trying to do. Spending a month fighting the borrow checked doesn't seem normal to me.

If you are implementing data structures and stuff, you might want to read more about the actual limitations of the borrow checker. Some kinds of code just can't be done with the constraints of the borrow checker. Embrace unsafe blocks and then gradually try to move as much code as possible away from those unsafe blocks. Try to think of "unsafe" as merely "unverified by the compiler". There is nothing inherently evil about unsafe.

If you are doing more application-level programming, I recommend you to get acquainted with the functional style of programming, if you haven't done this yet. Pick a more conventional language and then try to implement something using as few assignments as possible. Get used to and embrace immutability. Once you are used to immutability, Rust will be much easier too.

Re: Ask HN: How do I understand Rust?

#9

> It seems like everything I know about structuring a program goes out the window when borrowing comes into the picture. Try to avoid structured programming and mutable state where possible. Apply functional programming idioms and use immutable data structures if you can. Rust adopts many features from functional programming languages: http://science.raphael.poss.name/rust-for-functional-program... Borrow checker wil…

> there's nothing wrong with [unsafe code]

I suppose I must ask, then: why Rust?

Re: Ask HN: How do I understand Rust?

#10

> It seems like everything I know about structuring a program goes out the window when borrowing comes into the picture. Try to avoid structured programming and mutable state where possible. Apply functional programming idioms and use immutable data structures if you can. Rust adopts many features from functional programming languages: http://science.raphael.poss.name/rust-for-functional-program... Borrow checker wil…

> there's nothing wrong with [unsafe code] I suppose I must ask, then: why Rust?

The point is to contain them and hide them under nice safe abstractions. If you avoid unsafe rust at all costs, including unsafe rust hidden under abstractions, you'll find that you can't write any rust at all because the standard library is so full of unsafe rust.
Post reply on HN