3 ms·

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

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.

kibwen 8y ago
Regarding closures, note that Rust closures don't allocate on the heap unless you explicitly use a Box to put them on the heap. Long-lived closures aren't a problem, because closures by default borrow the variables they close over (and like all borrowed references, these cannot extend the overall lifetime of the borrowed data); alternatively they may take ownership of their closed-over variables, but in that case the closure can only be called exactly once (as expected for owned values).
- FreeFull 8y ago
  A closure taking ownership of the closed-over variables doesn't actually imply that it is FnOnce (only callable once). You can perfectly well have a Fn or FnMut closure that owns its captures, as long as you don't try to do any moves inside the closure. If you need to do a move in an FnMut closure, you can also wrap the captured variable in an Option, and use .take()
Annatar 8y ago
"Even in many functional languages, you typically want some OO" No, never, because it makes the state machine incredibly hard to follow and an absolute nightmare to debug. From experience.

kibwen 8y ago

Regarding closures, note that Rust closures don't allocate on the heap unless you explicitly use a Box to put them on the heap. Long-lived closures aren't a problem, because closures by default borrow the variables they close over (and like all borrowed references, these cannot extend the overall lifetime of the borrowed data); alternatively they may take ownership of their closed-over variables, but in that case the closure can only be called exactly once (as expected for owned values).

FreeFull 8y ago
A closure taking ownership of the closed-over variables doesn't actually imply that it is FnOnce (only callable once). You can perfectly well have a Fn or FnMut closure that owns its captures, as long as you don't try to do any moves inside the closure. If you need to do a move in an FnMut closure, you can also wrap the captured variable in an Option, and use .take()

Annatar 8y ago

"Even in many functional languages, you typically want some OO" No, never, because it makes the state machine incredibly hard to follow and an absolute nightmare to debug. From experience.