5 ms·

I remember writing Rust in university a year before this was published. How far the language has come since then! The title should be updated to include the dat

by vngzs 7y ago

I remember writing Rust in university a year before this was published. How far the language has come since then! The title should be updated to include the date. The first koan strikes me as a timeless lesson about the advantages of the borrow checker. I came out of it feeling as if I had learned something, though it was really what I knew all along: it was one of the reasons I wrote rust. The second felt tired. Of course OOP limits us to only objects! The third I can see as a larger story about programming. As it applies to Rust? Perhaps it is saying that it is OK to crawl through the crack in the wall between the guards. Or it simply embodies the culture of Rust at the time - one of a massive group of people getting their hands dirty and getting shit done. The fourth truly made me smile. Yes, its lesson about macros was correct - at least then. I doubt they have gotten much easier to use. However, they are useful to work with to get a feel for manipulating the raw syntax of the language. Writing some toys with them is sure to teach you a thing or two about using the language without them.

chrismorgan 7y ago
The second is about the separation of data and behaviour—Rust has structs, which are purely data, and implementations, inherent and of traits, which provide the behaviour. This is more flexible than classes which unite the two and tend to require that everything be in one place, and a Good Thing.
- ajross 7y ago
  > This is more flexible than classes Meh. Seems pretty 1:1 to me. Skipping the complexity with runtime polymorphism[1], there's no meaningful semantic difference between a Java interface or mixin-style C++ superclass or [insert abstraction from your favorite language here]. Frankly this is one of the bits of Rust that infuriates me, because while it's not a big deal nor hard to understand, it's senselessly different from the way the rest of the world does things. It's another obstacle to new programmers, in a language that is filled with booby traps for the newbie. [1] Let me state upfront the degree to which I am completely uninterested in debating the merits of multiple virtual inheritance vs. trait objects. They both suck. I guess if I had to pick C++ sucks a tiny bit less because you can implement something like a trait object in straightforward code, where Rust can't do vtables without boilerplating every method.
  - FridgeSeal 7y ago
    > it's senselessly different from the way the rest of the world does things. Because every way of doing "x" has already been tried and the way we do things _right_ _now_ is hands down the absolute best way right? Less snarkily, I think experimentation is good - we come up with new approaches and ways of doing things (which could solve any number of previously difficult problems) and helps prevent "monocultural" approaches to things. > It's another obstacle to new programmers... Why is it an obstacle rather than just something they learn? You could just as easily argue that the OO approach of wrapping up structure and functionality in a single object is equally "just another obstacle for new programmers". > in a language that is filled with booby traps for the newbie. That's a bit of an unfair statement, Rust has a learning curve, but it is certainly not filled with booby traps: it goes to great pains to make things transparent and be upfront about things. C++, JS or PHP are languages that I'd call filled with booby traps for beginners...
    - ajross 7y ago
      > Because every way of doing "x" has already been tried and the way we do things _right_ _now_ is hands down the absolute best way right? Absent evidence to the contrary, yeah. Generations of hackers have been expressing designs perfectly well with traditional class syntaxes. This is a long solved problem, and a skill you can rely on when moving between C++ or Java or C# or python or Ruby or JS (though Javascript tried to get fancy in this space too and had to bolt on traditional syntax later). But to get stuff working in rust you have to learn a different metaphor. That's bad a priori unless there's a clear advantage. And be real: there isn't, it's just syntax churn. To wit, if it ain't broke don't fix it.
      - worik 7y ago
        > And be real: there isn't, it's just syntax churn No. I have programmed in C, C++ and Rust. Rust is much different, and it is not "just syntax ..."
      - kd5bjo 7y ago
        > Generations of hackers have been expressing designs perfectly well with traditional class syntaxes. “Traditional class syntaxes” have existed for only half the time since people started thinking about object-oriented programming in the 1950s— C++ was only invented in 1983, and didn’t get popular until the mid-90s. That puts it in widespread use for only one generation, and about due to be supplanted by the next major paradigm (maybe async/promises/futures). It won’t go away, of course: structured, functional, and procedural programming are all standard tools used by most programmers today alongside object orientation. We just have enough experience with them to know what problems each is best and worst suited for, and this is what you’re seeing in Rust; it treats OOP as one useful tool in the toolbox instead of a panacea that makes everything better.
- taneq 7y ago
  OK, so I wasn't too far off in my (not-yet-Rust-programmer) interpretation of "duck typing is good (or at least more flexible)"?
  - mintplant 7y ago
    Rust's approach is very much not "duck typing".
    - taneq 7y ago
      The koan doesn't disambiguate, though, does it? If you didn't know it was about Rust, what clues are there that it's talking about static typing?
      - morgancmartin 7y ago
        I think you're right. I took the koan to mean that when designing any given widget the focus of the implementation should make as few contextual assumptions about the use of the widget as is it feasible to do. There is an inverse relationship between the number of contextual assumptions made about a widget and the number of contexts the widget can operate in. Something with few contextual assumptions is typically referred to as "flexible." Duck typing as a practice entails a focus on the capabilities of a given widget rather than the "role" (read: type) of that widget. Focus on capabilities = fewer contextual assumptions. Focus on role/type = more contextual assumptions. Thus duck typing can be thought of as one possible embodiment of the koan's intended perspective. Of course, some detractors of static typing might take this to mean that static typing implies a focus on types which as I've just shown would imply more contextual assumptions and less flexibility. But as rust's traits show, one can keep the benefits of static typing without sacrificing flexibility so long as the focus of the overall design is still capability-centric rather than role/type-centric. But that's a different conversation :)
jkoudys 7y ago
As someone who's been deep into rust for only a month, I can't imagine there was a time where macros were any _harder_ to figure out. That said, using macros that other people have written for me is pretty great. The procedural macros from serde -- Serialize and Deserialize -- are phenomenal. I don't think Rust would have half the value to me writing web apps if I didn't have those.

by vngzs 7y ago

chrismorgan 7y ago

The second is about the separation of data and behaviour—Rust has structs, which are purely data, and implementations, inherent and of traits, which provide the behaviour. This is more flexible than classes which unite the two and tend to require that everything be in one place, and a Good Thing.

ajross 7y ago
> This is more flexible than classes Meh. Seems pretty 1:1 to me. Skipping the complexity with runtime polymorphism[1], there's no meaningful semantic difference between a Java interface or mixin-style C++ superclass or [insert abstraction from your favorite language here]. Frankly this is one of the bits of Rust that infuriates me, because while it's not a big deal nor hard to understand, it's senselessly different from the way the rest of the world does things. It's another obstacle to new programmers, in a language that is filled with booby traps for the newbie. [1] Let me state upfront the degree to which I am completely uninterested in debating the merits of multiple virtual inheritance vs. trait objects. They both suck. I guess if I had to pick C++ sucks a tiny bit less because you can implement something like a trait object in straightforward code, where Rust can't do vtables without boilerplating every method.
- FridgeSeal 7y ago
  > it's senselessly different from the way the rest of the world does things. Because every way of doing "x" has already been tried and the way we do things _right_ _now_ is hands down the absolute best way right? Less snarkily, I think experimentation is good - we come up with new approaches and ways of doing things (which could solve any number of previously difficult problems) and helps prevent "monocultural" approaches to things. > It's another obstacle to new programmers... Why is it an obstacle rather than just something they learn? You could just as easily argue that the OO approach of wrapping up structure and functionality in a single object is equally "just another obstacle for new programmers". > in a language that is filled with booby traps for the newbie. That's a bit of an unfair statement, Rust has a learning curve, but it is certainly not filled with booby traps: it goes to great pains to make things transparent and be upfront about things. C++, JS or PHP are languages that I'd call filled with booby traps for beginners...
  - ajross 7y ago
    > Because every way of doing "x" has already been tried and the way we do things _right_ _now_ is hands down the absolute best way right? Absent evidence to the contrary, yeah. Generations of hackers have been expressing designs perfectly well with traditional class syntaxes. This is a long solved problem, and a skill you can rely on when moving between C++ or Java or C# or python or Ruby or JS (though Javascript tried to get fancy in this space too and had to bolt on traditional syntax later). But to get stuff working in rust you have to learn a different metaphor. That's bad a priori unless there's a clear advantage. And be real: there isn't, it's just syntax churn. To wit, if it ain't broke don't fix it.
    - worik 7y ago
      > And be real: there isn't, it's just syntax churn No. I have programmed in C, C++ and Rust. Rust is much different, and it is not "just syntax ..."
    - kd5bjo 7y ago
      > Generations of hackers have been expressing designs perfectly well with traditional class syntaxes. “Traditional class syntaxes” have existed for only half the time since people started thinking about object-oriented programming in the 1950s— C++ was only invented in 1983, and didn’t get popular until the mid-90s. That puts it in widespread use for only one generation, and about due to be supplanted by the next major paradigm (maybe async/promises/futures). It won’t go away, of course: structured, functional, and procedural programming are all standard tools used by most programmers today alongside object orientation. We just have enough experience with them to know what problems each is best and worst suited for, and this is what you’re seeing in Rust; it treats OOP as one useful tool in the toolbox instead of a panacea that makes everything better.
taneq 7y ago
OK, so I wasn't too far off in my (not-yet-Rust-programmer) interpretation of "duck typing is good (or at least more flexible)"?
- mintplant 7y ago
  Rust's approach is very much not "duck typing".
  - taneq 7y ago
    The koan doesn't disambiguate, though, does it? If you didn't know it was about Rust, what clues are there that it's talking about static typing?
    - morgancmartin 7y ago
      I think you're right. I took the koan to mean that when designing any given widget the focus of the implementation should make as few contextual assumptions about the use of the widget as is it feasible to do. There is an inverse relationship between the number of contextual assumptions made about a widget and the number of contexts the widget can operate in. Something with few contextual assumptions is typically referred to as "flexible." Duck typing as a practice entails a focus on the capabilities of a given widget rather than the "role" (read: type) of that widget. Focus on capabilities = fewer contextual assumptions. Focus on role/type = more contextual assumptions. Thus duck typing can be thought of as one possible embodiment of the koan's intended perspective. Of course, some detractors of static typing might take this to mean that static typing implies a focus on types which as I've just shown would imply more contextual assumptions and less flexibility. But as rust's traits show, one can keep the benefits of static typing without sacrificing flexibility so long as the focus of the overall design is still capability-centric rather than role/type-centric. But that's a different conversation :)

jkoudys 7y ago

As someone who's been deep into rust for only a month, I can't imagine there was a time where macros were any _harder_ to figure out. That said, using macros that other people have written for me is pretty great. The procedural macros from serde -- Serialize and Deserialize -- are phenomenal. I don't think Rust would have half the value to me writing web apps if I didn't have those.