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

61–67 of 67 posts

Re: Why Rust's ownership/borrowing is hard

#61

Post by steveklabnik »

pdpi wrote: post #58
steveklabnik wrote: post #52

Earlier quoted context omitted.

I have a lot of experience with Rust, so take this with a grain of salt, but as long as a library exists, I feel about 85% as productive with Rust as I do Ruby. While it takes slightly longer initially, I save a lot of time writing less tests and virtually never debugging. It's a much younger ecosystem, so there's not always a library though. Then it clearly takes longer, because there's a lot more to do. We do have…

On the contrary, your response is much more useful than anything I say, because your terms of comparison are much more apples-to-apples than anything my paltry rust experience can provide :)

Yeah but "Just code in Rust for three years and then it's easy!" needs a caveat.

Re: Why Rust's ownership/borrowing is hard

#62

Post by Manishearth »

tatterdemalion wrote: post #60
pdpi wrote: post #57

Earlier quoted context omitted.

Sorry, I wasn't clear. You are, of course, correct: you're only ever in a position to call a method if you hold a reference to the struct you're calling on. My meaning was that you should favour a usage pattern that looks like you either move/copy things into the called method, or lend a reference to something you own (which is, presumably, not going to be held on to for very long), and then you're either given owner…

Here is the issue: `self.foo.bar(self.baz())` is an error if `foo.bar()` mutates foo, even if `baz()` doesn't touch `foo` and even if `baz()` doesn't return a reference. This is because borrowck doesn't properly understand that baz will be evaluated before bar, and can't distinguish which elements of a struct are accessed by that struct's methods. Both of these are problems that can be solved, and neither of them is…

Yeah, this is basically a borrowck "bug" which will probably be fixed post-MIR.

Note that there are cases where such code is invalid even with the temporary, and they can be related to Demeter. Ish. Also to API contracts; the guarantee should be embedded in the signature (so changing the internals shouldn't cause its usage to stop compiling), which is unweildy to do.

Re: Why Rust's ownership/borrowing is hard

#63

Post by Manishearth »

jabl wrote: post #51
pdpi wrote: post #50

Earlier quoted context omitted.

I'm building a music synthesiser in Rust, and it's a joy to work with. If you're used to writing systems languages, you might want to learn it because it's the highest-level language I know that prays to the gods of zero cost abstraction. You still get all the control from C/C++ while gaining several convenient features. ADTs and pattern matching are personal favourites. It's widely known that Rust automates a lot of…

> If you're used to writing in the likes of javascript, python or ruby, Rust is a wonderful gateway drug to systems programming, and it's probably the most accessible alternative. So what do you think of productivity in Rust vs python/ruby/js? Is it a lot slower to implement something in Rust? While it has a lot of high level features, it doesn't strike me as particularly concise compared to, say, haskell or python..

I used to program in python a lot. A few months after I started programming in Rust, I realized that I was still more productive in python for small things, but for nontrivial applications (both writing one and changing an existing one), the type system lets me grok a lot of stuff very quickly (I don't have to figure out how an API can be used, the signature makes it obvious), and the safeguards let me program in a way that "If my code compiles, it probably works". This is less so the case with python, since you have to write a lot more tests and debug code. Of course, Rust still needs tests, just ... fewer (often). And as far as APIs go in python, I would often have to google how to do a specific thing. In Rust I often can copy the basic example, open the docs for the method call, and follow the strongly typed arguments in the doc page till I find the tweak I'm looking for. I have never felt the need to google how to do X with library Y in Rust, but after years of Python I still google this even for libraries I am familiar with since I dread trawling through the docs.

Conciseness isn't really an issue IMO. You can type fast, and your IDE can probably autocomplete. Note that the explicitness in Rust also makes it harder to make mistakes, so I feel that some extra code here and there isn't a bad price to pay.

Re: Why Rust's ownership/borrowing is hard

#64

Post by hinkley »

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…

When people asked my why I used Java this was pretty much my answer. I got tired of having to design all of my code around figuring out who owned the arguments, and what happened when it wasn't always the same answer. I can call a method that borrows the value from one that takes ownership, but I can't do vice versa.

I have six other things that will kill my app faster than a memory leak, but I have to design this shit first? No thank you. Rust is on my list of things to learn in 2016 and I'm hoping its borrowing semantics will feel like a solution to this problem without having to sign up for nondeterministic application pauses in the bargain.

Re: Why Rust's ownership/borrowing is hard

#65

Post by jabl »

Manishearth wrote: post #63
jabl wrote: post #51

Earlier quoted context omitted.

> If you're used to writing in the likes of javascript, python or ruby, Rust is a wonderful gateway drug to systems programming, and it's probably the most accessible alternative. So what do you think of productivity in Rust vs python/ruby/js? Is it a lot slower to implement something in Rust? While it has a lot of high level features, it doesn't strike me as particularly concise compared to, say, haskell or python..

I used to program in python a lot. A few months after I started programming in Rust, I realized that I was still more productive in python for small things, but for nontrivial applications (both writing one and changing an existing one), the type system lets me grok a lot of stuff very quickly (I don't have to figure out how an API can be used, the signature makes it obvious), and the safeguards let me program in a w…

That's nice to hear (python (and C) are my strongest languages ATM), and what you describe is one thing which irks me when programming with python.

As for conciseness, I do think it matters; it's not about how fast you type really, but how fast you can read what you wrote a week later. But conciseness is perhaps a bit of a blunt term, and maybe needs a bit of qualifiers. Now, take this with a large grain of salt due to my very limited knowledge of Rust. But, say, for a short program/script I guess python "wins" clearly since you can just let it bomb out with a stack trace if something goes wrong, whereas in Rust you have more explicit type conversions (.to_string() etc.), and you have to handle errors somehow, even if it's just with try!/unwrap() etc. which adds clutter. But for a larger program, maybe the difference isn't so big anymore, since Rust, unusually for a "close-to-the-metal" language, has a lot of higher-level functional-style features, and for python you probably want to handle errors in some way anyhow?

Re: Why Rust's ownership/borrowing is hard

#66

Post by Manishearth »

jabl wrote: post #65
Manishearth wrote: post #63

Earlier quoted context omitted.

I used to program in python a lot. A few months after I started programming in Rust, I realized that I was still more productive in python for small things, but for nontrivial applications (both writing one and changing an existing one), the type system lets me grok a lot of stuff very quickly (I don't have to figure out how an API can be used, the signature makes it obvious), and the safeguards let me program in a w…

That's nice to hear (python (and C) are my strongest languages ATM), and what you describe is one thing which irks me when programming with python. As for conciseness, I do think it matters; it's not about how fast you type really, but how fast you can read what you wrote a week later. But conciseness is perhaps a bit of a blunt term, and maybe needs a bit of qualifiers. Now, take this with a large grain of salt due…

Yeah, so I find that "how fast you can read what you wrote a week later" is easier in Rust for larger codebases, but for small codebases python is a very clear win.

Eventually you'll learn to glance over unwrap() and try!() (well, unwrap() less so, since it's a bad idea to keep it around in your code) and the code you're reading becomes pretty straightforward to read.

My one annoyance in reading Rust code is that because of type inference (which is a super awesome feature otherwise and this annoyance is nowhere close to being enough to make me dislike it) you sometimes don't know the type of the thing being worked on, so getting an idea of what the code is doing is harder (of course, python has the same issue with dynamic types). I've recently started using YouCompleteMe, though, which has pretty decent "Jump To Definition" support which lets me quickly jump around the types and figure out what's happening in such cases.

Re: Why Rust's ownership/borrowing is hard

#67

Post by steveklabnik »

gulpahum wrote: post #34
dikaiosune wrote: post #3

There were also some interesting comments yesterday when this was posted to the Rust subreddit: https://www.reddit.com/r/rust/comments/45gcmh/why_rusts_owne...

There was one good point, which was also my conclusion: "Given all that, I wonder if it makes sense to prefer plain old functions most of the time. Is that right, or am I overlooking something?" The response was yes. Avoid impl methods which take a mutable self.

I wouldn't characterize it this way. There was a whole thread on just this question: https://www.reddit.com/r/rust/comments/45j6ua/why_dont_we_pr...
Post reply on HN