How do you get back something owned by something else?
You don't, unless they pass it to you (as a return value or function argument).
Or if the borrow doesn't outlive the source e.g. if a local goes out of scope.
The Rust borrow checker from a different perspective
11–20 of 51 posts
Re: The Rust borrow checker from a different perspective
#12From that writeup, it seems like one is forced to program Rust in an object oriented manner. Is it possible to program it in a functional manner like Lisp, or a procedural manner like BASIC or assembler?
Just to be clear, rust is not object oriented. You do not use inheritance nor do you have objects.
There was a recent post comparing rust to haskell https://www.fpcomplete.com/blog/2018/10/is-rust-functional. And tldr is yes it lends itself to a functional style...
Re: The Rust borrow checker from a different perspective
#13Earlier quoted context omitted.
Can someone chime in as to why C++ compilers in particular are notorious for extremely verbose yet unhelpful error messages? Is it something endemic to parsing the language that there can't be errors as helpful as Rust's?
As well as templates, C++ has function overloading, so when a function is named in an error message it has to show all the arguments as well. And if it can't find a function variant that matches a call, it'll print out a "did you mean this one?" message for all of them.
And of course C++ harks back to an era where error messages were not considered much of a concern. It took the Clang project for C compilation errors to start improving (including kicking gcc's ass), and C is not the most difficult language to parse/validate.
Re: The Rust borrow checker from a different perspective
#14From that writeup, it seems like one is forced to program Rust in an object oriented manner. Is it possible to program it in a functional manner like Lisp, or a procedural manner like BASIC or assembler?
In my experience, it’s not much more OO than Haskell. Even in many functional languages, you typically want some OO — you’ll want some core type that you export opaquely, and then you have functions doing logical operations on that.
I think two of the biggest differences are:
- Because the type and memory systems make it possible to skip heap allocation if you’re careful, it’s “idiomatic” to prefer avoiding techniques that still require it. This means avoiding long-lived closures. Note that closures still are used very heavily, but typically aren’t passed around between many owners like in Lisp or JavaScript.
- Similarly, because Rust can give you incredible safety and speed if you use it a certain way, people tend to write with interior mutability very often. However, unlike in most languages, Rust’s type systems is a tremendous help to the programmer with mutability, and it’s much, much more likely that you’ll see interior mutability done right. It allows you to program in a style that feels very functional even while using many imperative components. A lot of your code still ends up as basic pattern matching and simple closures.
Re: The Rust borrow checker from a different perspective
#15From that writeup, it seems like one is forced to program Rust in an object oriented manner. Is it possible to program it in a functional manner like Lisp, or a procedural manner like BASIC or assembler?
I wouldn't say that object oriented is completely opposed to functional, though.
Re: The Rust borrow checker from a different perspective
#16From that writeup, it seems like one is forced to program Rust in an object oriented manner. Is it possible to program it in a functional manner like Lisp, or a procedural manner like BASIC or assembler?
Rust is like C++, but with different syntax and an ability to make the use-after-moved-from a compile-time error.
So it's a multi-paradigm language where any manner of coding is possible.
Re: The Rust borrow checker from a different perspective
#17How do you get back something owned by something else?
I don't see that big a deal. In a language, say Ada, I would pass in an "IN" parameter, which cannot be altered in a procedure (and by default in a function). In other languages I would keep the scope/lifetime extremely small, and just not mutate or leak memory. This is just plain ol' good programming practice IMHO.
Is there another more compelling use case. In concurrent applications perhaps?
Re: The Rust borrow checker from a different perspective
#18From that writeup, it seems like one is forced to program Rust in an object oriented manner. Is it possible to program it in a functional manner like Lisp, or a procedural manner like BASIC or assembler?
Just to be clear, rust is not object oriented. You do not use inheritance nor do you have objects. There was a recent post comparing rust to haskell https://www.fpcomplete.com/blog/2018/10/is-rust-functional . And tldr is yes it lends itself to a functional style...
> And tldr is yes it lends itself to a functional style
Rust does a good job of supporting a functional style efficiently. It's also considered idiomatic to code functionally. Probably the biggest, obvious exception is that Rust embraces mutability because it's statically safe to do so i.e. you aren't as susceptible to the traditional disadvantages of mutability.
> You do not use inheritance nor do you have objects
That's only partially true though. Rust does support interface inheritance and polymorphism in its trait system. And enums are a closed form of sub-typing. RAII is also idiomatic and I'd argue that many would class that as object-oriented.
The way I'd characterise the OO approach in Rust is that the team looked at the experiences of using OO in other languages and picked out what they considered the valuable pieces and left the dangerous ones (like implementation inheritance).
Re: The Rust borrow checker from a different perspective
#19As someone who is not familiar with Rust at all, wow—what refreshingly helpful error messages!
Can someone chime in as to why C++ compilers in particular are notorious for extremely verbose yet unhelpful error messages? Is it something endemic to parsing the language that there can't be errors as helpful as Rust's?
I suspect it's the inverse: the Rust compiler team has specifically put a lot of effort into good error messages, whereas for C++ compiler developers it's been a low priority. Some of the inspiration came from Elm [1], which has famously good error messages.
[1] https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...
Re: The Rust borrow checker from a different perspective
#20How do you get back something owned by something else?
Return it from a method, or store it into a field of an object you already own.