Ask HN: How do I understand Rust? • Hacker News Board

Re: Ask HN: How do I understand Rust?

#31

Post by wyager » Sat, Jan 28, 2017, 12:35 AM UTC

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).

Indirect the graph connections. This is almost always a better design anyway. Instead of storing pointers from one graph node to another, give each node an identifier and store a map from identifiers to nodes. Each node then has a set (or other collection) of identifiers it's connected to.

You can use either a mutable or immutable map for this construction.

Re: Ask HN: How do I understand Rust?

#32

Post by sidlls » Sat, Jan 28, 2017, 12:41 AM UTC

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…

I come from a C++ background, and I quite happily used references, const references, and move operations regularly. I dare say, a good bit of the code I wrote was a C++-analogue to the Rust code I write. It's just that the mutability differences reduce the code I have to look at considerably (e.g. instead of "const &" I simply have "&" and instead of "&" I have "&mut"--which reduces the quantity of code considerably).

I have been programming with C++ before the C++-0x and later standards introduced some of these concepts (e.g. move) and since, and the move to Rust (as far as the borrow checker is concerned) has been mostly smooth.

I think "I come from C++" isn't as important as the kind of C++ one has been used to.

Re: Ask HN: How do I understand Rust?

#33

Post by itamarst » Sat, Jan 28, 2017, 12:48 AM UTC

Object ownership varies widely by language (I just wrote up a survey of why - https://codewithoutrules.com/2017/01/26/object-ownership/), and no one ever teaches object ownership as an explicit skill (it's always implicit with each language's semantics). So it's pretty natural that switching styles would be difficult.

Perhaps if you understood why these are rules are in place, or compare to other rules from other languages? GNOME project has nice strict rules for C: https://developer.gnome.org/programming-guidelines/unstable/...

(Full disclosure: never written any Rust, have just skimmed docs.)

Re: Ask HN: How do I understand Rust?

#34

Post by flubert » Sat, Jan 28, 2017, 12:55 AM UTC

iopq wrote: post #26

xjia wrote: post #16

Earlier quoted context omitted.

> 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.

>it's rare to actually manually recurse in Haskell

I wonder if there is a semi-easy way to measure this. My impression was that while the papers and tutorials are all about combinators, the people writing Haskell "in the wild" tend to go with general recursion more often than you might expect.

Re: Ask HN: How do I understand Rust?

#35

Post by the8472 » Sat, Jan 28, 2017, 1:05 AM UTC

wyager wrote: post #31

amelius wrote: post #22

Earlier quoted context omitted.

> 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).

Indirect the graph connections. This is almost always a better design anyway. Instead of storing pointers from one graph node to another, give each node an identifier and store a map from identifiers to nodes. Each node then has a set (or other collection) of identifiers it's connected to. You can use either a mutable or immutable map for this construction.

That's basically the "don't keep references into a Vec, keep indices" advise. I don't really like that because references explicitly encode the dependency in the type system. When you start juggling indices you're basically implementing poor man's malloc. You need to make sure you don't lose track of any of them.

I think owned objects should have lifetimes and a "points to non-moving memory" property. E.g. a vec can be moved and must outlive all the objects that take references from it. That way it would be possible to keep an owned object and refs to it in the same struct and pass the whole bundle around.

Re: Ask HN: How do I understand Rust?

#36

Post by komone » Sat, Jan 28, 2017, 1:08 AM UTC

I'd say that Rust is telling you that you don't correctly understand your use of shared data. This should be looked upon as a great prompt to figure it out.

I faced a similar issue with "getting" Rust. I found that a close reading of https://doc.rust-lang.org/book/ownership.html and subsequent sections - backed up by Chapter 5 of the O'Reilly book "Programming Rust" - the most useful way forward.

It's still harder, but the code I have as a result is much, much more robust than it would otherwise have been.

Re: Ask HN: How do I understand Rust?

#37

Post by [deleted] » Sat, Jan 28, 2017, 1:12 AM UTC

[deleted]

Re: Ask HN: How do I understand Rust?

#38

Post by stcredzero » Sat, Jan 28, 2017, 1:25 AM UTC

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

You can substitute concurrency for borrowing. Congrats. You're on the path towards understanding another paradigm. You're on your way to expanding your mind and growing a bunch of new neural connections. The learning curve means the eventual triumph will be that much better.

Re: Ask HN: How do I understand Rust?

#39

Post by iopq » Sat, Jan 28, 2017, 1:47 AM UTC

flubert wrote: post #34

iopq wrote: post #26

Earlier quoted context omitted.

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.

>it's rare to actually manually recurse in Haskell I wonder if there is a semi-easy way to measure this. My impression was that while the papers and tutorials are all about combinators, the people writing Haskell "in the wild" tend to go with general recursion more often than you might expect.

Even if you recurse, it doesn't mean you can make it tail-recursive. It might be a style issue, but Rust programmers are just going to use combinators instead anyway since recursion is slower.

Re: Ask HN: How do I understand Rust?

#40

Post by bascule » Sat, Jan 28, 2017, 1:58 AM UTC

Whenever someone asks this question, I point them at this...

Learning Rust With Entirely Too Many Linked Lists: http://cglab.ca/~abeinges/blah/too-many-lists/book/

The point of this tutorial is not "wow it's hard to write linked lists in Rust", but that Rust supports a number of different memory models, and this tutorial takes you through each of them by writing a linked list using each one.

Additionally, it's snarky and entertaining.

All that said, I think it's a really good crash course on the Rust memory model, and once you have your brain wrapped around the various approaches, it should hopefully make it easier to understand how to avoid encountering those borrow checker errors.