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

41–50 of 61 posts

Re: Ask HN: How do I understand Rust?

#41

Post by guycook »

steamer25 wrote: post #25
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 .

And if compile times are getting you down, you can still get the checks without producing a binary and save quite a bit of time with https://github.com/rsolomo/cargo-check

Re: Ask HN: How do I understand Rust?

#43

Post by civility »

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

Store your graph as an adjacency matrix, using either a 2D array of edges (if your problem is small enough), or as a sparse matrix (hash table or similar).

Re: Ask HN: How do I understand Rust?

#44

Post by nbouscal »

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

There's a decent amount of research into functional graph algorithms. The right approach depends on the application, but two interesting ones are inductive graphs[1] and zippers[2].

I also agree with other commenters that you should make certain you actually need your arbitrarily complicated graph, though.

[1]: http://web.engr.oregonstate.edu/~erwig/papers/InductiveGraph... [2]: https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf

Re: Ask HN: How do I understand Rust?

#45

Post by joseph »

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.

This is what I've tried to do when learning Rust. However, I find it ends up more boilerplatey than a language like Haskell. I had to do lots of clone() and iter(), which cluttered up the functional idioms. Maybe I'm doing it wrong though.

Re: Ask HN: How do I understand Rust?

#46

Post by steveklabnik »

wyldfire wrote: post #11

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

Yes. OP, please drop by IRC, the forums, or Reddit. We are extremely happy to work through issues and help explain what's going on, generally. Half the time during US working hours you'll literally get me.

Re: Ask HN: How do I understand Rust?

#47

Post by steveklabnik »

joseph wrote: post #45
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. This is what I've tried to do when learning Rust. However, I find it ends up more boilerplatey than a language like Haskell. I had to do lots of clone() and iter(), which cluttered up the functional idioms. Maybe I'm doing it wrong though.

Rust makes deep copies explicit, whereas those languages don't. So if you program in the exact same style, it will be a bit more verbose; Rust is exposing a cost here.

That said, idiomatic Rust does lean a bit more functional than many languages.

Re: Ask HN: How do I understand Rust?

#48

Post by steveklabnik »

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 not guaranteed, though LLVM may do it if it feels like it. We may gain guaranteed TCO in the future, we'll see.

Re: Ask HN: How do I understand Rust?

#49

Post by bbatha »

guycook wrote: post #41
steamer25 wrote: post #25

Earlier quoted context omitted.

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

And if compile times are getting you down, you can still get the checks without producing a binary and save quite a bit of time with https://github.com/rsolomo/cargo-check

That's built in now!

Re: Ask HN: How do I understand Rust?

#50

Post by lobster_johnson »

bogomipz wrote: post #29
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 c…

In C++ the closest equivalent is probably unique_ptr [1], which only lets one reference exist at any given time and destroys the pointer when it goes out of scope, but also allows transferring the ownership to someone else. The C++ equivalent of Rust's Rc (reference counted pointer) is std::shared_ptr.

[1] http://en.cppreference.com/w/cpp/memory/unique_ptr

Post reply on HN