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

Why Rust's ownership/borrowing is hard

softwaremaniacs.org

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Why Rust's ownership/borrowing is hard

#11

Post by cm3 »

cm3 wrote: post #10
steveklabnik wrote: post #7

Earlier quoted context omitted.

That way the syntax is the same everywhere. Reference by default would look different, and then you'd need a sigil for move, etc. pcwalton said that back in the 0.1 days this was actually implemented, and it was very confusing.

I remember it but the language changed so often that I didn't recall this right away. At least it's tried and scrapped and not based on some opinion.

I mean, like in Haskell the hard earned wisdom is that laziness should probably have been opt-in like OCaml making you write the rec keyword for recursive functions. I hope that one day we will get TCO in Rust as it's natural to implement many things recursively.

Re: Why Rust's ownership/borrowing is hard

#12

Post by [deleted] »

jonreem wrote: post #8
cm3 wrote: post #4

Why is move the default? In many code bases the number of immutable references outweighs that of pointers.

In early rust, you actually did need to explicitly write `move` to move a value. However, this was extremely annoying as you move values a lot so moving was changed to be the default, which is far more tolerable. EDIT: There still is a `move` keyword, but it is used to indicate that closures should take ownership of their environment vs. just borrow values from it, not to move individual values.

[deleted]

Re: Why Rust's ownership/borrowing is hard

#14

Post by jerf »

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects."

I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it's just that the language doesn't help you.

Re: Why Rust's ownership/borrowing is hard

#15

Post by ajdlinux »

jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

Yes. I'm still just learning it myself - I've got to say it's a really nice break from writing C (which is most of my day job). Having a proper type system is really nice, and having type inference makes me feel like I'm coding in a dynamic language even though I'm not.

I'm currently building a CI tool (which will hopefully be open sourced once I get approval from our legal department) with a colleague of mine who mostly chose to use Rust because he needed an excuse to learn it...

Re: Why Rust's ownership/borrowing is hard

#16

Post by dikaiosune »

jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

I've found it very fruitful. I had previously spent a couple of months hacking away at a project in C++ which needed lots of fine-grained parallelism and custom data structures (metagenomics analysis tool). When we decided to shift our approach and that we wouldn't be saving any code, I started out trying Rust and fell in love. Many of the issues I faced in trying to quickly put together an application in C++ were just non-issues as a result of Rust's type system.

Re: Why Rust's ownership/borrowing is hard

#17

Post by pron »

jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

> I'd submit it doesn't create them... it reveals them. They've always been there.

Hopefully, but not necessarily. Any (decidable) type system rejects well-typed programs (i.e., it "uncovers" problems that are not actually there), and the borrow checker is no exception. You will write some correct Rust programs that the borrow-checker just can't verify. This means that you will need to explain yourself in more detail (through more work) to the type checker, even though there was no mistake in your program. I think this is a good thing (depending on your requirements), but it isn't free.

Re: Why Rust's ownership/borrowing is hard

#18

Post by Animats »

jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

Exactly. C programming has three big questions: "How big is it", "who releases it", and "who locks it". The language gives little help with any of those issues. C++ tries to address all three, but the mechanisms were all painfully retrofitted using templates and they leak.

In the example in the article, "is_origin(point)", the code for which is not shown, is clearly bogus. A function that's just a predicate should not consume its input. It should use read-only access by reference.

One big advantage of Rust is that, because the ownership checking is safe, you don't have to make copies of things just to simplify memory allocation control. In some C++ GUI libraries, strings are copied again and again to prevent memory allocation errors. Rust should be more efficient. It's going to be interesting to see if Servo puts a dent in browser memory consumption. It's insane that browsers now can need more than 1GB of RAM. There have to be multiple copies of the same data.

Re: Why Rust's ownership/borrowing is hard

#19

Post by pjmlp »

jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

Yes, the more languages the better, even if you don't use them on the day job, you will be exposed to new ways of thinking and problem solving.

On my case, just dabbling given my background as language geek.

Re: Why Rust's ownership/borrowing is hard

#20

Post by pjmlp »

dikaiosune wrote: post #16
jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

I've found it very fruitful. I had previously spent a couple of months hacking away at a project in C++ which needed lots of fine-grained parallelism and custom data structures (metagenomics analysis tool). When we decided to shift our approach and that we wouldn't be saving any code, I started out trying Rust and fell in love. Many of the issues I faced in trying to quickly put together an application in C++ were ju…

One of our customers is using C# for sequencing and it is quite fast for his datasets.

Of course, using Rust is even cooler.

Post reply on HN