5 ms·

From 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

From 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?

zkomp 8y ago
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 https://www.fpcomplete.com/blog/2018/10/is-rust-functional. And tldr is yes it lends itself to a functional style...
- lucozade 8y ago
  > 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).
  - masklinn 8y ago
    > That's only partially true though. Rust does support interface inheritance and polymorphism in its trait system. It supports no more than Haskell's typeclasses (rather less in fact), are typeclasses an object system? > And enums are a closed form of sub-typing. Rust enums are pretty standard sum types, a staple of statically typed functional languages. > RAII is also idiomatic and I'd argue that many would class that as object-oriented. That's defensible but setting one hell of a low bar on the concept of object orientation.
    - lucozade 8y ago
      > are typeclasses an object system No, did someone say they were? > Rust enums are pretty standard sum types, a staple of statically typed functional languages Indeed I'm not entirely sure what your point is. Functional and OO aren't mutually exclusive.
      - Annatar 8y ago
        "Functional and OO aren't mutually exclusive." They must by definition be. I disagree vehemently with your statement. If you were correct, then there would be absolutely no point to programming "functionally", it would be absurd. Might as well go back to programming in Java or C++, which is utterly counterproductive.
        indeyets 8y ago
        "functional" is a description of algorithm (or program), but not language. Languages usually have ways to program in different styles.
        Annatar 8y ago
        No, functional programming is a paradigm. An algorithm is a language independent, abstract description of solving a specific task, like for instance searching or sorting.
        Jtsummers 8y ago
        Functional programming and object oriented programming are (largely) orthogonal issues. It is, in fact, quite possible to combine both approaches in a language. Java and C++ are really imperative + OOP, not pure OO. The closest to pure OO are going to be languages like Smalltalk which still has some imperative concepts and some concepts from functional programming (closures and higher order functions via blocks, in particular). Scheme allows for object oriented programming, though not directly in the base language spec. You have to build out some infrastructure for it, but then it's quite effective for it.
      - 8y ago
- Annatar 8y ago
  lorry.pickup(&rustfest_envelope); lorry.done(); looks like methods on an object ("lorry") to me. Is it something else?
  - steveklabnik 8y ago
    Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.
    - kjeetgill 8y ago
      Interesting. I'm coming from Java that looks-like an object to me. I assume method dispatch here is based on the "receiver" as well right? What differentiates it from an object? Not having identity? or Not being self describing (like a.getClass()) maybe? Thank you for the insight.
      - steveklabnik 8y ago
        No problem! Syntax is just syntax. Imagine a function that takes two 32-bit numbers, and adds them together: fn foo(x: i32, y: i32) -> i32 { x + y } You'd call it like this: foo(5, 6) // would give back 11 However, this is just syntax. There's no reason this can't be 5.foo(6) It's purely a different way of calling the same thing. The first argument goes before the dot. In some languages, this is 100% interchangable. In Rust, it's not 100%, but it's pretty true. For example, the wrapping_add method adds two numbers together, wrapping around if the number is too large. These are equivalent: let x: i32 = 5; assert_eq!(x.wrapping_add(5), 10); assert_eq!(i32::wrapping_add(x, 5), 10); You can use either method or function call style. These aren't objects, they're just primitive 32 bit numbers. There's no heap allocation, there's no extra bookeeping info. There are some more details, but that's the basic idea. Does that make sense?
    - Annatar 8y ago
      What difference does it make how one calls it if I have to program the same way I'd have to program if I were using object oriented paradigm? Or even worse, if I'm forced to debug and understand code written in object-oriented style, how does that help debug and understand the program? It's a travesty this syntax or anything resembling object-oriented programming is allowed. By the by, the best programming languages aren't ones where there is more than one way to do it, but ones where there is one and exactly one way to do any given thing and the reason is simple: the code is easier to understand and therefore enhance or debug for anyone proficient in that language; in addition, it reduces the total number of mistakes in software written in such a language. AWK is one example of such a language.
wwright 8y ago
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.
ealhad 8y ago
I wouldn't say that object oriented is completely opposed to functional, though.
- YorkshireSeason 8y ago
  Indeed, Scala's main innovation was to demonstrate that functional programming is a well-behaved edge-case of OO programming. (Before Scala, research was mostly trying to show the opposite: how OO is an edge case of FP, but that didn't work quite so well.)
- Annatar 8y ago
  I would. That's the whole point: in object-oriented programming, everything revolves around the state machine, whereas in functional programming, every function is idempotent and the state machine irrelevant. Lisp is a good example of that.
  - ealhad 8y ago
    Are you giving Lisp as an example of functional or object-oriented programming? I mean, Common Lisp has had CLOS since at least 1984.
    - Annatar 8y ago
      Functional of course.
      - ealhad 8y ago
        That's what I thought. And yet, object-oriented programming is quite common in many Lisps.
de_watcher 8y ago
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.
masklinn 8y ago
> From that writeup, it seems like one is forced to program Rust in an object oriented manner. That's really not the case. In fact I'd say the opposite, the focus on ownership, limitations of the borrow checker (partial borrows through function calls) and lack of inheritance makes "object oriented programming" rather difficult. That functions are commonly namespaced through traits or structs does not intrinsically make it "object oriented". It has a number of functional APIs (many standard structures have various HoFs for manipulating them and combining them), although the ownership and borrow checking bits can also make them somewhat less convenient.

zkomp 8y ago

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 https://www.fpcomplete.com/blog/2018/10/is-rust-functional. And tldr is yes it lends itself to a functional style...

lucozade 8y ago
> 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).
- masklinn 8y ago
  > That's only partially true though. Rust does support interface inheritance and polymorphism in its trait system. It supports no more than Haskell's typeclasses (rather less in fact), are typeclasses an object system? > And enums are a closed form of sub-typing. Rust enums are pretty standard sum types, a staple of statically typed functional languages. > RAII is also idiomatic and I'd argue that many would class that as object-oriented. That's defensible but setting one hell of a low bar on the concept of object orientation.
  - lucozade 8y ago
    > are typeclasses an object system No, did someone say they were? > Rust enums are pretty standard sum types, a staple of statically typed functional languages Indeed I'm not entirely sure what your point is. Functional and OO aren't mutually exclusive.
    - Annatar 8y ago
      "Functional and OO aren't mutually exclusive." They must by definition be. I disagree vehemently with your statement. If you were correct, then there would be absolutely no point to programming "functionally", it would be absurd. Might as well go back to programming in Java or C++, which is utterly counterproductive.
      - indeyets 8y ago
        "functional" is a description of algorithm (or program), but not language. Languages usually have ways to program in different styles.
        Annatar 8y ago
        No, functional programming is a paradigm. An algorithm is a language independent, abstract description of solving a specific task, like for instance searching or sorting.
      - Jtsummers 8y ago
        Functional programming and object oriented programming are (largely) orthogonal issues. It is, in fact, quite possible to combine both approaches in a language. Java and C++ are really imperative + OOP, not pure OO. The closest to pure OO are going to be languages like Smalltalk which still has some imperative concepts and some concepts from functional programming (closures and higher order functions via blocks, in particular). Scheme allows for object oriented programming, though not directly in the base language spec. You have to build out some infrastructure for it, but then it's quite effective for it.
    - 8y ago
Annatar 8y ago
lorry.pickup(&rustfest_envelope); lorry.done(); looks like methods on an object ("lorry") to me. Is it something else?
- steveklabnik 8y ago
  Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.
  - kjeetgill 8y ago
    Interesting. I'm coming from Java that looks-like an object to me. I assume method dispatch here is based on the "receiver" as well right? What differentiates it from an object? Not having identity? or Not being self describing (like a.getClass()) maybe? Thank you for the insight.
    - steveklabnik 8y ago
      No problem! Syntax is just syntax. Imagine a function that takes two 32-bit numbers, and adds them together: fn foo(x: i32, y: i32) -> i32 { x + y } You'd call it like this: foo(5, 6) // would give back 11 However, this is just syntax. There's no reason this can't be 5.foo(6) It's purely a different way of calling the same thing. The first argument goes before the dot. In some languages, this is 100% interchangable. In Rust, it's not 100%, but it's pretty true. For example, the wrapping_add method adds two numbers together, wrapping around if the number is too large. These are equivalent: let x: i32 = 5; assert_eq!(x.wrapping_add(5), 10); assert_eq!(i32::wrapping_add(x, 5), 10); You can use either method or function call style. These aren't objects, they're just primitive 32 bit numbers. There's no heap allocation, there's no extra bookeeping info. There are some more details, but that's the basic idea. Does that make sense?
  - Annatar 8y ago
    What difference does it make how one calls it if I have to program the same way I'd have to program if I were using object oriented paradigm? Or even worse, if I'm forced to debug and understand code written in object-oriented style, how does that help debug and understand the program? It's a travesty this syntax or anything resembling object-oriented programming is allowed. By the by, the best programming languages aren't ones where there is more than one way to do it, but ones where there is one and exactly one way to do any given thing and the reason is simple: the code is easier to understand and therefore enhance or debug for anyone proficient in that language; in addition, it reduces the total number of mistakes in software written in such a language. AWK is one example of such a language.

wwright 8y ago

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.

ealhad 8y ago

I wouldn't say that object oriented is completely opposed to functional, though.

YorkshireSeason 8y ago
Indeed, Scala's main innovation was to demonstrate that functional programming is a well-behaved edge-case of OO programming. (Before Scala, research was mostly trying to show the opposite: how OO is an edge case of FP, but that didn't work quite so well.)
Annatar 8y ago
I would. That's the whole point: in object-oriented programming, everything revolves around the state machine, whereas in functional programming, every function is idempotent and the state machine irrelevant. Lisp is a good example of that.
- ealhad 8y ago
  Are you giving Lisp as an example of functional or object-oriented programming? I mean, Common Lisp has had CLOS since at least 1984.
  - Annatar 8y ago
    Functional of course.
    - ealhad 8y ago
      That's what I thought. And yet, object-oriented programming is quite common in many Lisps.

de_watcher 8y ago

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.

masklinn 8y ago

> From that writeup, it seems like one is forced to program Rust in an object oriented manner. That's really not the case. In fact I'd say the opposite, the focus on ownership, limitations of the borrow checker (partial borrows through function calls) and lack of inheritance makes "object oriented programming" rather difficult. That functions are commonly namespaced through traits or structs does not intrinsically make it "object oriented". It has a number of functional APIs (many standard structures have various HoFs for manipulating them and combining them), although the ownership and borrow checking bits can also make them somewhat less convenient.