Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do I understand Rust?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Ask HN: How do I understand Rust?

#21

Post by alfiedotwtf »

"I keep end up fighting the compiler with borrowing errors."

To set expectations, I tell everyone that I've encouraged to try Rust that they will hit this same problem, then hate themselves and want to give up on computers and live in a cave. Once they understand that they aren't just going to "get" Rust in four hours reading the book while Seinfeld is on in the background, I tell them that when they get frustrated with the borrow checker, just re-read the "Ownership" and "References and Borrowing", "Lifetimes" chapters from the book and then rinse and repeat. I tell them that by the fourth or fifth time it will "just click". So far, so good.

I know this isn't the most ideal method, but until it's cemented, you don't really understand the mechanics of what you're able to get away with. Persist... we've all gone through your frustrations, but can see the awesome bright light at the end of the tunnel (no, it's not a train).

Re: Ask HN: How do I understand Rust?

#22

Post by amelius »

ycmbntrthrwaway wrote: post #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 wil…

> Apply functional programming idioms and use immutable data structures if you can.

How would you implement efficient and flexible graph algorithms using these techniques? E.g., considering that edges need to be traversed quickly, updated quickly, etc., and graphs are arbitrarily complicated (not just trees or DAGs).

Re: Ask HN: How do I understand Rust?

#23

Post by steeleduncan »

I found that my brawls with Rust's borrow checker ended when I made ownership the focus of my code design. Coming from a C++/Objc/Go background I was used to creating an object on the heap and holding a reference counted/garbage collected pointer to the object wherever it was used. This is shared ownership of state, a style of coding Rust considers to be so egregious that it is a compile error.

Initially I would use constructs such as Rc> in an attempt to write Rust code in my old style. It took some time for me to realise that Rust's borrow checker was not just designed to avoid occasional data races, but shared ownership of state as a whole, and the problems it causes. Once I ceased trying to resolve each localised problem with the borrow checker, and I designed my code such that each and every object has a clear owner responsible for creating, maintaining and destroying it at all times during execution, I have had no further problems.

At the point you "get it", it is worth comparing the code you eventually wrote to the code you would have written initially. For me, it seemed that Rust's borrow checker had forced me to code in a better, safer style, rather than brainwashing me into thinking it had, so I have continued using Rust.

Re: Ask HN: How do I understand Rust?

#24

Post by steamer25 »

Basics:

When you're writing (or read someone else's) functions, you should be considering three types of parameters:

  * (&)     borrowed
  * (mut &) mutably borrowed
  * ()      moved
The borrow operator should be your default/go-to decoration. Don't use the more destructive exchanges until the compiler forces you to. As I write this out, I'm thinking this might be a small short-coming in Rust's design. I.e., read/borrowed should maybe be the default/undecorated behavior and special pains should be required to move a reference.

Anyway, borrowed means, "I just wanna read some stuff off of that. I promise not to change a thing!"

Mutable borrowing means, "Gimme that--I'm going to change it! Expect it to differ as part of the output of this function."

Moving means, "That's mine now! I'm going to wreck it beyond any usage you'd try to do after I'm done. If you think you still want it, better hand me a clone."

It might also be good to spend some time working through the book if you haven't already: https://doc.rust-lang.org/stable/book/

Here're some HN comments about advanced patterns:

  * https://news.ycombinator.com/item?id=13470592#13470904
  * https://news.ycombinator.com/item?id=13470975
    * Also recommends http://cglab.ca/~abeinges/blah/too-many-lists/book/

Re: Ask HN: How do I understand Rust?

#25

Post by steamer25 »

steamer25 wrote: post #24

Basics: When you're writing (or read someone else's) functions, you should be considering three types of parameters: * (&) borrowed * (mut &) mutably borrowed * () moved The borrow operator should be your default/go-to decoration. Don't use the more destructive exchanges until the compiler forces you to. As I write this out, I'm thinking this might be a small short-coming in Rust's design. I.e., read/borrowed should…

Also, save and recompile early and often. If you're using IntelliJ IDEA [Community Edition] with the Rust plugin, compiling is just ctrl + r .

Re: Ask HN: How do I understand Rust?

#26

Post by iopq »

xjia wrote: post #16
ycmbntrthrwaway wrote: post #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 wil…

> functional programming idioms Proper tail recursion was still missing last time I checked. Does it affect functional programming in Rust?

It's rare to actually use tail-recursive algorithms in Rust since those can be written with a loop, which Rust does support.

I mean, it's rare to actually manually recurse in Haskell too, and when you need to, it's often not something you can write tail-recursively.

Re: Ask HN: How do I understand Rust?

#27

Post by ideasman42 »

Hey, I also started learning Rust not so long ago (~5 months).

By the sounds of it didn't have quite as much trouble as you're experiencing.

Having said that, I found experienced Rust developers grossly under estimate how hard it is for newcomers to the language (having asked questions on Reddit's r/rust which gave the impression these are some concepts developers can learn, then move on without too many troubles).

A re-occurring problem I found is while everything I could read made sense on paper - composing concepts to make real-world, you run into _many_ random problems that you don't even have the vocabulary to properly question or troubleshoot.

I found this works well:

* Ask general big-picture questions on Reddit.

* Ask spesific technical questions on StackOverflow.

* Ask various short/general questions on IRC (#rust).

As for fighting the borrow checker and compiler errors generally - ask some more experienced Rust developers if you're taking the wrong approach entirely. If this project is too complicated, try pick some simple projects where you're not continuously running into borrow checking errors. You'll still hit them from time-to-time, but then at least you're not overwhelmed by compiler errors.

Re: Ask HN: How do I understand Rust?

#28

Post by winstonewert »

amelius wrote: post #22
ycmbntrthrwaway wrote: post #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 wil…

> Apply functional programming idioms and use immutable data structures if you can. How would you implement efficient and flexible graph algorithms using these techniques? E.g., considering that edges need to be traversed quickly, updated quickly, etc., and graphs are arbitrarily complicated (not just trees or DAGs).

Curious: what kind of graph structures do you typically find yourself writing? Maybe I'm just doing different stuff, but I find myself with tree or DAGs in almost all cases.

Re: Ask HN: How do I understand Rust?

#29

Post by bogomipz »

steeleduncan wrote: post #23

I found that my brawls with Rust's borrow checker ended when I made ownership the focus of my code design. Coming from a C++/Objc/Go background I was used to creating an object on the heap and holding a reference counted/garbage collected pointer to the object wherever it was used. This is shared ownership of state, a style of coding Rust considers to be so egregious that it is a compile error. Initially I would use…

>" Coming from a C++/Objc/Go background I was used to creating an object on the heap and holding a reference counted/garbage collected pointer to the object wherever it was used. This is shared ownership of state, a style of coding Rust considers to be so egregious that it is a compile error."

Is the idea that because anyone else can come along and make reference to the same object on the heap mean "shared" in this context? If so would the opposite of "shared" be "owned" or "owned exclusively"? Is this what borrow checker is "checking" then?

Post reply on HN