Live data from Hacker News

The Rust borrow checker from a different perspective

blog.systems.ethz.ch

41–50 of 51 posts

Re: The Rust borrow checker from a different perspective

#41

Earlier quoted context omitted.

> 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.

> No, did someone say they were? You're implying that Rust's traits "partially" make for an object system. Given Rust's trait are essentially a restricted form of Haskell's typeclass, these would by your assertion "partially"+ make for an object system as well.

No, I was stating that Rust's trait system offer functionality that supports an OO style of programming.

That doesn't really have anything to do with whether one can or cannot call Haskell's typeclasses an object system.

Re: The Rust borrow checker from a different perspective

#42
post #6

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

C++ template system is too generic (Turing complete), and it is usually the one to blame for the verboseness of error messages.

Something like Concepts would probably make it more like a proper "generics" mechanism and allow better error messages - ie, "this type does not implement EqualityTrait" instead of "signature mismatch and ".

Despite this, newer g++ versions have better error messages overall - but sometimes you are stuck with an older version of the compiler as well.

Re: The Rust borrow checker from a different perspective

#43
post #32

Earlier quoted context omitted.

> 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.

"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.

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.

Re: The Rust borrow checker from a different perspective

#44
post #30

Earlier quoted context omitted.

lorry.pickup(&rustfest_envelope); lorry.done(); looks like methods on an object ("lorry") to me. Is it something else?

Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.

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.

Re: The Rust borrow checker from a different perspective

#45

Earlier quoted context omitted.

Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.

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.

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?

Re: The Rust borrow checker from a different perspective

#46
post #37
post #33

Earlier quoted context omitted.

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.

Are you giving Lisp as an example of functional or object-oriented programming? I mean, Common Lisp has had CLOS since at least 1984.

Functional of course.

Re: The Rust borrow checker from a different perspective

#47
post #32

Earlier quoted context omitted.

"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.

"functional" is a description of algorithm (or program), but not language. Languages usually have ways to program in different styles.

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.

Re: The Rust borrow checker from a different perspective

#48
post #30

Earlier quoted context omitted.

lorry.pickup(&rustfest_envelope); lorry.done(); looks like methods on an object ("lorry") to me. Is it something else?

Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.

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.

Re: The Rust borrow checker from a different perspective

#49
post #46
post #37

Earlier quoted context omitted.

Are you giving Lisp as an example of functional or object-oriented programming? I mean, Common Lisp has had CLOS since at least 1984.

Functional of course.

That's what I thought. And yet, object-oriented programming is quite common in many Lisps.

Re: The Rust borrow checker from a different perspective

#50
post #48

Earlier quoted context omitted.

Yes. Rust does not have objects. Method call syntax isn’t inherent to objects.

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…

Because OO is more than method call syntax, so you wouldn’t be doing those things the same way that you would in an OO language, since Rust is not OO.
Post reply on HN