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

11–20 of 61 posts

Re: Ask HN: How do I understand Rust?

#11

Post by wyldfire »

> I'm really not sure where to turn for help.

I get most of my help on #rust on IRC. But for those who don't prefer that the discourse site https://users.rust-lang.org/ is probably idea. Or if you prefer reddit, do /r/rust -- they have a weekly sticky thread for questions IIRC.

The community is super friendly so "I'm really not sure where to turn for help" should be easy to solve. IMO just keep asking questions until you can internalize the rules you're getting help with.

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

I know squat about borrowing rules, but why not just toss things on the heap (is that 'Arc'?) until you get better?

BTW -- do you already have some familiarity with 'C'? IMO that might be a simpler place to start. It has virtually none of the borrowing rules but perhaps you could quickly find out why they exist in Rust.

Re: Ask HN: How do I understand Rust?

#12

Post by buzzybee »

Try a "back-to-basics" approach of writing less structured code, as in, factor it less, use more plain data structures, just write straight-line imperative blocks of code. This is actually the path of least resistance in most languages, but they all offer shiny features and don't stop you from overcomplicating it by prematurely distributing functionality into abstractions.

Re: Ask HN: How do I understand Rust?

#13

Post by ycmbntrthrwaway »

JacksonGariety wrote: post #9
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…

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

If you keep unsafe code in modules and don't pass raw pointers in between, it is much easier to audit the code. All the glue code is automatically safe. Then each module can be audited separately to make sure it is impossible to make it crash by using public API.

Rust `collections' library is full of unsafe code. Just for example: https://doc.rust-lang.org/src/collections/up/src/libcollecti... But you can never leave a BTree in an invalid state by adding or removing elements. Given safe collections library you can write lots of applications without resorting to unsafe code and having to prove the safety of your code.

Proving safety of B-Trees, threaded code and things like that requires a whole theorem prover that Rust most likely will never provide. You need to use Coq or similar tool if you are developing new algorithms and data structures. But if you are not a pure computer science researcher, most likely you don't need it. All you have to do is to carefully translate pseudocode from paper into Rust and package it.

Re: Ask HN: How do I understand Rust?

#14

Post by MichaelGG »

Do you understand how to write code in, say, C? Like do you understand the scope of manually managing memory, not making memory safety errors? When I run into borrow checker errors I try to think through exactly who owns what and who will free it when.

Re: Ask HN: How do I understand Rust?

#15

Post by winstonewert »

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…

I have to second the use of immutable data structures. That is the style I'd adopted prior to using rust, and in learning Rust I've found that I've hardly ever fought with the borrow checker.

Suggesting unsafe code seems like a bad move, if haven't mastered the borrow checker, is learning the dark magic of unsafe a good plan?

Re: Ask HN: How do I understand Rust?

#16

Post by xjia »

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?

Re: Ask HN: How do I understand Rust?

#17

Post by nonsince »

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…

The rest of the points here are excellent, but don't use `unsafe` until you have completely internalised the borrow checker rules. If your safe attempt is unsafe (and therefore doesn't pass the borrow checker), your unsafe code will be unsafe too. The only difference is that the unsafe code won't be caught at compile-time.

Re: Ask HN: How do I understand Rust?

#20

Post by zphds »

Here's my understanding. Please correct me if I am wrong. Visualizing your program as a tree of values that are borrowed, owned, mutated through variables helps in reasoning about the borrow checker

When a variable owning a value goes out of scope all the children goes with it. Remember in rust, there can only be one owner to a value (Rc and Arc variables lets you have multiple owners but that's for special cases). Therefore, if you're passing a variable to a function you should either

1.) transfer ownership to the function being called.

2.) have the function being called borrow the value through references. Since this doesn't transfer any ownership you can have multiple references to the same value. The value and its children (think of a Vec) are taken down from the tree it belongs when the variable owning this value goes out of scope.

That's the cool thing that does rust does. The compiler knows when to free things just by following this one rule. A value should have only one owner. The responsibility of managing memory is now taken by the compiler instead. Hence no dangling pointers or segmentation fault unless you use `unsafe` blocks where this assurance isn't valid anymore.

Visualize your program to be manipulating these multiple trees made up of diverse types.

Post reply on HN