17 ms·

"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed tha

by copx 9y ago

"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed that the above wasn't in Rust to begin with, though. Can't think of any other languages which has classes but no class methods/variables.

jandrese 9y ago
Now you have me wondering what use a class is without methods or variables. It's just a namespace?
- dbaupp 9y ago
  "class methods" are specifically static methods, meaning they don't have a self/this object. Rust's closest equivalent to classes has always allowed normal methods and variables (as well as class/static methods, just not class/static "variables").
- e12e 9y ago
  Threadsafe (no externally visible mutable data) singleton instance?
  - jandrese 9y ago
    Isn't all data (outside of unsafe blocks) in Rust already threadsafe? Isn't that one of the big selling points of the language?
    - wahern 9y ago
      Rust isn't inherently thread-safe; not like in the way Java is thread-safe because of how the JVM's memory model is defined. Rust makes it really difficult to share mutable data. But once you do that, such as by smuggling a pointer _through_ an unsafe block, all bets are off, even for code outside an unsafe block. Also, as with Java there will always be bugs in the compiler and runtime. Rust programs were susceptible to StackClash just as much as C applications. No matter what language you use, if you minimize shared mutable data you'll minimize thread-safety issues.
      - CrystalGamma 9y ago
        If you use a C FFI in any language, including Java, all kinds of safety are off. Unsafe Rust is equivalent to C (with a lot of mandatory lints) in terms of safety, so Rust is not really less safe.
        alphaalpha101 9y ago
        Not necessarily. There is no actual reason that you couldn't be required to prove to the compiler that your code is safe. That proof might be parameterised by a proof that some external FFI function was safe, which you might not be able to actually prove and have to assume, but then you would have your assumptions well-documented. As it is, you have to justify the safety of your unsafe blocks to other programmers using comments, which kind of sucks. Still better than every other fast language in this area though so I can't complain much.
      - jandrese 9y ago
        I get that all bets are off once an unsafe() block is in play, but in the intended use case it seems like it should be safe.
        kibwen 9y ago
        You are correct there. Though we can quibble over the definition of "thread safety", concurrent memory safety is a subset of memory safety, which safe Rust enforces (or at least intends to enforce, modulo bugs).
    - steveklabnik 9y ago
      It is data-race free. That's one definition of "threadsafe", but there could be others; it's a pretty broad term.
dbaupp 9y ago
NB. associated functions have always existed. Also, to be a little snide: "Modules" = modules "Concepts" = traits C++ keeps approaching Rust's feature set! It's normal and even expected that languages in a similar space will either draw inspiration from each other or converge on similar solutions.
- steveklabnik 9y ago
  What's funny about this is that I had worded it even less clearly, and it was changed due to feedback: https://github.com/rust-lang/blog.rust-lang.org/pull/192#discussion_r135933426 https://github.com/rust-lang/blog.rust-lang.org/pull/192#dis... Guess I didn't go far enough :)
  - EmanueleAina 9y ago
    Maybe "In previous Rust versions you could already define traits, ..."?
    - steveklabnik 9y ago
      Sounds great, thank you! https://github.com/rust-lang/blog.rust-lang.org/commit/e74c57dd8e18b213219623e7ad51f978b85aafdc https://github.com/rust-lang/blog.rust-lang.org/commit/e74c5...
kibwen 9y ago
You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly subsumes classes themselves).
- copx 9y ago
  >Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too. Oh and calling an interface a "trait" does not change its fundamental nature either. Rust clearly is an OOP language.
  - dbaupp 9y ago
    Having aggregate data types and syntactically having methods seems like a very facile definition of "OOP", versus the conventional uses referring to Smalltalk style message passing or inheritance and overrides. Other than being able to call functions as x.foo() rather than foo(x) or foo x or similar, languages like Haskell and C seem to satisfy the requirements for being OOP, which seems to make "OOP" completely useless as a category. In any case, this point is been argued at length for every language, including Rust.
    - sanxiyn 9y ago
      I actually think having syntactic methods is an important (if not the most important) part of "OOP". You compared x.foo() with foo(x), but that's the wrong comparison. The correct comparison is that when x if of type Tree, x.foo() vs tree_foo(x). Otherwise you get name clashes. That is, I think the essence of "OOP", OOP-as-used, not any theoretical OOP, is function name resolution depending on type. That and syntax. So first, you write x.tree_foo() instead of tree_foo(x) which is purely syntactic. And then you shorten x.tree_foo() to x.foo(), because x is a tree, which is a great semantic help. According to this definition, Haskell and C are not "OOP", which matches common understanding.
steveklabnik 9y ago
I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book (https://doc.rust-lang.org/book/second-edition/ch17-00-oop.html https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht...) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit into either of the three major schools of OOP, which I personally nickname the "smalltalk school", the "java school", or the "javascript school".
- zaphar 9y ago
  Obviously Rust is in the 4'th school which I like to call "The Rust School". All kidding aside, I think for any regular working day programmer Rust is obviously OOP. The debates are really just which parts of which favorite school of OOP you think Rust is inspired by. But what really matters is that Rust gives you: * Encapsulation * Polymorphism. * And Code Reuse. Which are the only three things anyone who reaches for OOP is really looking for anyway. As fun as the PL theory discussions are. (Kind of a Hobby for me at least) I think those are the bits that actually matter to the people who truly need an answer to the question "Is Rust OOP or not?"
  - steveklabnik 9y ago
    > Obviously Rust is in the 4'th school which I like to call "The Rust School". Ha! But yeah, if you're going to claim Rust is OOP, I would argue that makes the most sense. > what really matters is that Rust gives you: Right, this is the "Java School" definition. However, when people talk about OOP this way, when they say "polymorphism", they mean "subtype polymorphism" not "parametric polymorphism." Take https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html https://docs.oracle.com/javase/tutorial/java/IandI/polymorph... as an example. Rust's only sub-typing is for lifetimes. > As fun as the PL theory discussions are. I definitely agree that in some senses, this is academic. But at the same time, practitioners can be mis-led by using terms in a different way than they're used to. This is sort of the argument I'm making above; since many practitioners see "polymorphism" as being equal to "subtype polymorphism", calling other types of polymorphism "polymorphism" is a more academic, less user-focused distinction.
deleted 9y ago
[deleted]
tatterdemalion 9y ago
Associated consts allows constants to be derived from our trait-constrained parametric polymorphism. C++ currently has no analog to this system (templates can be used, but don't provide a constraint system; concepts are not in C++17 afaik). At an introductory level, like this announcement, we teach this system by analogy to OO, but its not OO in its core and snide comments like this only reveal the limits of your knowledge.
- steveklabnik 9y ago
  > concepts are not in C++17 afaik That's correct, though they have been added to the C++20 draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0734r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p073...
tomjakubowski 9y ago
> Rust keeps approaching C++'s feature set.. If there's one thing we C++ programmers can agree on, it's that having tons of features makes C++ a pleasure to work with... ?
- trapperkeeper74 9y ago
  Maybe by "pleasure" they mean "obscurity, gotchas and complexity are pleasurable because they trip up newbies and lend themselves to job security."
- jmcomets 9y ago
  I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance), templates, type-erasing. Then I got a full time job working with a large C++ codebase. Since then I've been dealing with: - uninitialized variables / members - NULL checks - buffer overflows, especially with C-strings - (mutable) global variables - exception safety All these things don't exist in (safe) Rust. I'm sold. Foot note: the only thing I'm really missing in Rust right now is specialization in generics, which is being worked on here: https://github.com/rust-lang/rust/issues/31844 https://github.com/rust-lang/rust/issues/31844.
  - PopsiclePete 9y ago
    That's my main beef with C++. You read a book and it's beautiful - no uninitialized memory, safety, no C arrays/strings, RAII everywhere, it's clean, fast.....then you get to the "real world" and realize that 99% of C++ programmers are pretty f###ing horrible at their job and should've just stuck to naked C because at least then you'd be able to pin-point the bugs easier. So C++ is a wonderful language - in a world that only exists in the creators' heads, or on committee tables, or on brand-new, post C++03 codebases. Basically - nowhere.
    - ryl00 9y ago
      But isn't that the case with basically ANY programming language? Once its use becomes widespread, escaping the confines of the highly skilled early adapters, you can be sure a whole lot of dodgy code will be written in it.
pjmlp 9y ago
Regarding languages with OOP support, but lacking class methods. - Object Pascal (in the TP days) - Modula-3 - Oberon, Oberon-2, Active Oberon, Oberon-07 - Component Pascal You need to resort to plain functions/procedures instead.

by copx 9y ago

jandrese 9y ago

Now you have me wondering what use a class is without methods or variables. It's just a namespace?

dbaupp 9y ago
"class methods" are specifically static methods, meaning they don't have a self/this object. Rust's closest equivalent to classes has always allowed normal methods and variables (as well as class/static methods, just not class/static "variables").
e12e 9y ago
Threadsafe (no externally visible mutable data) singleton instance?
- jandrese 9y ago
  Isn't all data (outside of unsafe blocks) in Rust already threadsafe? Isn't that one of the big selling points of the language?
  - wahern 9y ago
    Rust isn't inherently thread-safe; not like in the way Java is thread-safe because of how the JVM's memory model is defined. Rust makes it really difficult to share mutable data. But once you do that, such as by smuggling a pointer _through_ an unsafe block, all bets are off, even for code outside an unsafe block. Also, as with Java there will always be bugs in the compiler and runtime. Rust programs were susceptible to StackClash just as much as C applications. No matter what language you use, if you minimize shared mutable data you'll minimize thread-safety issues.
    - CrystalGamma 9y ago
      If you use a C FFI in any language, including Java, all kinds of safety are off. Unsafe Rust is equivalent to C (with a lot of mandatory lints) in terms of safety, so Rust is not really less safe.
      - alphaalpha101 9y ago
        Not necessarily. There is no actual reason that you couldn't be required to prove to the compiler that your code is safe. That proof might be parameterised by a proof that some external FFI function was safe, which you might not be able to actually prove and have to assume, but then you would have your assumptions well-documented. As it is, you have to justify the safety of your unsafe blocks to other programmers using comments, which kind of sucks. Still better than every other fast language in this area though so I can't complain much.
    - jandrese 9y ago
      I get that all bets are off once an unsafe() block is in play, but in the intended use case it seems like it should be safe.
      - kibwen 9y ago
        You are correct there. Though we can quibble over the definition of "thread safety", concurrent memory safety is a subset of memory safety, which safe Rust enforces (or at least intends to enforce, modulo bugs).
  - steveklabnik 9y ago
    It is data-race free. That's one definition of "threadsafe", but there could be others; it's a pretty broad term.

dbaupp 9y ago

NB. associated functions have always existed. Also, to be a little snide: "Modules" = modules "Concepts" = traits C++ keeps approaching Rust's feature set! It's normal and even expected that languages in a similar space will either draw inspiration from each other or converge on similar solutions.

steveklabnik 9y ago
What's funny about this is that I had worded it even less clearly, and it was changed due to feedback: https://github.com/rust-lang/blog.rust-lang.org/pull/192#discussion_r135933426 https://github.com/rust-lang/blog.rust-lang.org/pull/192#dis... Guess I didn't go far enough :)
- EmanueleAina 9y ago
  Maybe "In previous Rust versions you could already define traits, ..."?
  - steveklabnik 9y ago
    Sounds great, thank you! https://github.com/rust-lang/blog.rust-lang.org/commit/e74c57dd8e18b213219623e7ad51f978b85aafdc https://github.com/rust-lang/blog.rust-lang.org/commit/e74c5...

kibwen 9y ago

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly subsumes classes themselves).

copx 9y ago
>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too. Oh and calling an interface a "trait" does not change its fundamental nature either. Rust clearly is an OOP language.
- dbaupp 9y ago
  Having aggregate data types and syntactically having methods seems like a very facile definition of "OOP", versus the conventional uses referring to Smalltalk style message passing or inheritance and overrides. Other than being able to call functions as x.foo() rather than foo(x) or foo x or similar, languages like Haskell and C seem to satisfy the requirements for being OOP, which seems to make "OOP" completely useless as a category. In any case, this point is been argued at length for every language, including Rust.
  - sanxiyn 9y ago
    I actually think having syntactic methods is an important (if not the most important) part of "OOP". You compared x.foo() with foo(x), but that's the wrong comparison. The correct comparison is that when x if of type Tree, x.foo() vs tree_foo(x). Otherwise you get name clashes. That is, I think the essence of "OOP", OOP-as-used, not any theoretical OOP, is function name resolution depending on type. That and syntax. So first, you write x.tree_foo() instead of tree_foo(x) which is purely syntactic. And then you shorten x.tree_foo() to x.foo(), because x is a tree, which is a great semantic help. According to this definition, Haskell and C are not "OOP", which matches common understanding.

steveklabnik 9y ago

I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book (https://doc.rust-lang.org/book/second-edition/ch17-00-oop.html https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht...) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit into either of the three major schools of OOP, which I personally nickname the "smalltalk school", the "java school", or the "javascript school".

zaphar 9y ago
Obviously Rust is in the 4'th school which I like to call "The Rust School". All kidding aside, I think for any regular working day programmer Rust is obviously OOP. The debates are really just which parts of which favorite school of OOP you think Rust is inspired by. But what really matters is that Rust gives you: * Encapsulation * Polymorphism. * And Code Reuse. Which are the only three things anyone who reaches for OOP is really looking for anyway. As fun as the PL theory discussions are. (Kind of a Hobby for me at least) I think those are the bits that actually matter to the people who truly need an answer to the question "Is Rust OOP or not?"
- steveklabnik 9y ago
  > Obviously Rust is in the 4'th school which I like to call "The Rust School". Ha! But yeah, if you're going to claim Rust is OOP, I would argue that makes the most sense. > what really matters is that Rust gives you: Right, this is the "Java School" definition. However, when people talk about OOP this way, when they say "polymorphism", they mean "subtype polymorphism" not "parametric polymorphism." Take https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html https://docs.oracle.com/javase/tutorial/java/IandI/polymorph... as an example. Rust's only sub-typing is for lifetimes. > As fun as the PL theory discussions are. I definitely agree that in some senses, this is academic. But at the same time, practitioners can be mis-led by using terms in a different way than they're used to. This is sort of the argument I'm making above; since many practitioners see "polymorphism" as being equal to "subtype polymorphism", calling other types of polymorphism "polymorphism" is a more academic, less user-focused distinction.

deleted 9y ago

[deleted]

tatterdemalion 9y ago

Associated consts allows constants to be derived from our trait-constrained parametric polymorphism. C++ currently has no analog to this system (templates can be used, but don't provide a constraint system; concepts are not in C++17 afaik). At an introductory level, like this announcement, we teach this system by analogy to OO, but its not OO in its core and snide comments like this only reveal the limits of your knowledge.

steveklabnik 9y ago
> concepts are not in C++17 afaik That's correct, though they have been added to the C++20 draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0734r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p073...

tomjakubowski 9y ago

> Rust keeps approaching C++'s feature set.. If there's one thing we C++ programmers can agree on, it's that having tons of features makes C++ a pleasure to work with... ?

trapperkeeper74 9y ago
Maybe by "pleasure" they mean "obscurity, gotchas and complexity are pleasurable because they trip up newbies and lend themselves to job security."
jmcomets 9y ago
I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance), templates, type-erasing. Then I got a full time job working with a large C++ codebase. Since then I've been dealing with: - uninitialized variables / members - NULL checks - buffer overflows, especially with C-strings - (mutable) global variables - exception safety All these things don't exist in (safe) Rust. I'm sold. Foot note: the only thing I'm really missing in Rust right now is specialization in generics, which is being worked on here: https://github.com/rust-lang/rust/issues/31844 https://github.com/rust-lang/rust/issues/31844.
- PopsiclePete 9y ago
  That's my main beef with C++. You read a book and it's beautiful - no uninitialized memory, safety, no C arrays/strings, RAII everywhere, it's clean, fast.....then you get to the "real world" and realize that 99% of C++ programmers are pretty f###ing horrible at their job and should've just stuck to naked C because at least then you'd be able to pin-point the bugs easier. So C++ is a wonderful language - in a world that only exists in the creators' heads, or on committee tables, or on brand-new, post C++03 codebases. Basically - nowhere.
  - ryl00 9y ago
    But isn't that the case with basically ANY programming language? Once its use becomes widespread, escaping the confines of the highly skilled early adapters, you can be sure a whole lot of dodgy code will be written in it.

pjmlp 9y ago

Regarding languages with OOP support, but lacking class methods. - Object Pascal (in the TP days) - Modula-3 - Oberon, Oberon-2, Active Oberon, Oberon-07 - Component Pascal You need to resort to plain functions/procedures instead.