• r00ty@kbin.life
    link
    fedilink
    arrow-up
    74
    ·
    1 month ago

    The problem with rust, I always find is that when you’re from the previous coding generation like myself. Where I grew up on 8 bit machines with basic and assembly language that you could actually use moving into OO languages… I find that with rust, I’m always trying to shove a round block in a square hole.

    When I look at other projects done originally in rust, I think they’re using a different design paradigm.

    Not to say, what I make doesn’t work and isn’t still fast and mostly efficient (mostly…). But one example is, because I’m used to working with references and shoving them in different storage. Everything ends up surrounded by Rc<xxx> or Rc<RefCell<xxx>> and accessed with blah.as_ptr().borrow().x etc.

    Nothing wrong with that, but the code (to me at least) feels messy in comparison to say C# which is where I do most of my day job work these days. But since I see often that things are done very different in rust projects I see online, I feel like to really get on with the language I need a design paradigm shift somewhere.

    I do still persist with rust because I think it’s way more portable than other languages. By that I mean it will make executable files for linux and windows with the same code that really only needs the standard libraries installed on the machine. So when I think of writing a project I want to work on multi platforms, I’m generally looking at rust first these days.

    I just realised this is programmerhumor. Sorry, not a very funny comment. Unless you’re a rust developer and laughing at my plight of trying to make rust work for me.

    • 2xsaiko@discuss.tchncs.de
      link
      fedilink
      arrow-up
      14
      ·
      1 month ago

      Do you have some public code you could link to that you’re having this issue with? There isn’t a one-size-fits-all solution for Rc/RefCell, I think.

      • r00ty@kbin.life
        link
        fedilink
        arrow-up
        16
        ·
        edit-2
        1 month ago

        The current thing I’m working on (processor for iptv m3u files) isn’t public yet, it’s still in the very early stages. Some of the “learning to fly” rust projects I’ve done so far are here though:

        https://git.nerfed.net/r00ty/bingo_rust (it’s a multi-threaded bingo game simulator, that I made because of the stand-up maths video on the subject).
        https://git.nerfed.net/r00ty/spectrum_screen (this is a port of part of a general CPU emulation project I did in C#, it emulates the ZX spectrum screen, you can load in the 6912 byte screens and it will show it in a 2x scaled window).

        I think both of these are rather using Arc<RwLock<Thing>> because they both operate in a threaded environment. Bingo is wholly multi-threaded and the spectrum screen is meant to be used by a CPU emulator running in another thread. So not quite the same thing. But you can probably see a lot of jamming the wrong shape in the wrong hole in both of those.

        The current project isn’t multi-threaded. So it has a lot of the Rc/Rc<RefCell> action instead.

        EDIT: Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

        Likewise the same channel objects are stored in the structure for the Excel file that is read in (searched for in the m3u file structure).

        BTreeMaps used because in different scenarios the contents will be output in either name order or channel order. So just better to put them in, in that order in the first place.

        • 2xsaiko@discuss.tchncs.de
          link
          fedilink
          arrow-up
          4
          ·
          1 month ago

          The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

          I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… https://dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

          Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

          So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

          struct Channels {
            data: Vec<Channel>,
            by_number: BTreeMap<u32 /* or whatever */, usize>,
            by_name: BTreeMap<String, usize>,
          }
          
          // untested but I think it should compile
          fn get_channel_by_name(ch: &Channels, name: &str) -> Option<&Channel> {
            Some(&self.data[*ch.by_name.get(name)?])
          }
          
          • r00ty@kbin.life
            link
            fedilink
            arrow-up
            2
            ·
            1 month ago

            The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

            The C# original uses the equivalent of read/write locks. But I found it problematic to work the same way in rust and then discovered the communication option was far easier to implement and actually avoids holding up threads. So went with that. Much easier and much faster in execution I think.

            I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

            In reality I’m never likely to remake the CPU project in rust. Firstly because I’d need to entirely re-engineer it because it’s extensively using hierarchical classes, which just doesn’t work the same way in rust. And I’m not sure traits would allow me to do things in even close to the same way. But if it were to work with a CPU emulator they need to share the memory, and also the CPU needs its own thread.

            So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

            This was something I was thinking about the other evening. I needed to get the index to remove some other data anyway and wondered if I’d be better off having a master vector and usize lookups for that data store. It’s one extra lookup, but by index it’s the tiniest and the speed isn’t a real issue anyway. It’s replacing perl scripts pulling data from mysql. It couldn’t possibly run slower than that :P

            Thanks for the commentary though and I think I’m going to make the changes to use indices to lookup data. I wanted to re-order the way things are done a bit anyway. The problem I see potentially is that the lookups probably need to be regenerated every time I delete something. But actually I think that since it is rebuilt from a file on load. Maybe I just remove the items from the lookups and leave them in the vector. Since next run they would be gone anyway.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      8
      ·
      1 month ago

      I find these videos give a very visual explanation and help to put you into the right mindset: http://intorust.com/
      (You can skip the first two videos.)

      Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
      I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.

      To make it a bit more concrete:
      You will have functions which hold ownership over some data, typically because they instantiated a struct. These sit at the root of a sub-tree, where you pass access to this data down into further functions by borrowing it to them.

      You don’t typically want to pass ownership all over the place, nor do you typically want to borrow (or pass references) to functions which are not part of this sub-tree.
      Of course, there’s situations where this isn’t easily possible, e.g. when having two independent threads talking to each other, and then you do need Rc or Arc, but yeah, the vast majority of programming problems can be solved with trees of function calls.

      • r00ty@kbin.life
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
        I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.

        Yes, this ties in with what I’m saying though. You need a paradigm shift in your design philosophy, which is hard when you come from a Cx background.

        I also think that in OO there shouldn’t be much cross contamination. It happens (and it happens a lot in my personal projects to be fair) but when well designed it shouldn’t need to be. In C# for example it should be the case that rather than a function owning a resource, a class should. So when using an object between classes you take it as a reference from a method in one class and pass it into a method to another class rather than call that class and make it a dependency of that class too. In this way you would have a one way dependency, rather than a two way.

        This kind of thinking has moved into creating objects in rust. Also I think yes within a same class the idea of a function (that isn’t static) accepting an object that is part of the class that was returned by another function in the case class feels very wrong from a Cx style point of view. If we knew we were going to do that, we’d just make it a class level variable and use it in both functions.

        Like I say, just another way of thinking and I’m not there yet.

  • fmstrat@lemmy.nowsci.com
    link
    fedilink
    English
    arrow-up
    39
    ·
    edit-2
    1 month ago

    Fun story from before Rust was getting popular (years ago). So, I did a performance comparison to determine what language we should write our rules engine in. I compared Go, Rust, Node, and some others not worth mentioning.

    At the time, I had experience with all but Rust.

    Even knowing nothing, and working from scratch, the Rust POC was significantly faster. Just way, way, better.

    That being said, I still chose Go due to productivity based on the language knowledge of the team to ease the transition (Go was closer to what they knew already), and while it was good for them to learn Go, I look back on it and realize Rust would have been a great opportunity to invest in their careers and have them learn it instead.

    A hindsight is 20/20 experience for me.

  • flying_gel@lemmy.world
    link
    fedilink
    arrow-up
    35
    ·
    1 month ago

    I do appreciate how newer C++ standards have made these kinds of things a lot easier too.

    Define all comparison operators with just one one line using C++20

    auto operator<=>(const ClassName&) const = default;

    • xor@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      44
      arrow-down
      1
      ·
      1 month ago

      It’s nice that this exists these days, but my god is it horrendously unreadable at a glance

      • Ephera@lemmy.ml
        link
        fedilink
        arrow-up
        7
        ·
        1 month ago

        It makes it look like they’re just adding random noise to avoid colliding with existing syntax. Maybe they can try a UUID next time…

        • flying_gel@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          1 month ago

          It makes perfect sense actually. I did write another comment here if you are interested.

          This is how operator overloads were written going back to the initial version of C++ back in 1985. The only new thing is that we can now add = default to get the compiler to generate a default implementation that compares all the member variables for you.

      • tetris11@lemmy.ml
        link
        fedilink
        arrow-up
        20
        ·
        1 month ago

        You just need to break the syntax apart and look at it from the LHS and the RHS seperately.

        In layman’s terms: constantine felt boxed in by his social class which left him often at dagger-ends to the operations on his car. Unable to keep up with the constant payments, he defaulted on the loan.

        See? Easy.

      • flying_gel@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        1 month ago

        Maybe to a non C++ dev, but a lot of C++ is probably incomprehensible to a non C++ dev, just like there are other laguages that are incomprehensible to C++ devs. To me it makes perfect sense as it works just like all the other operator overloads.

        auto - let the compiler deduce return type

        operator<=> - override the spaceship operator (pretty sure it exists in python too)

        (const ClassName&) - compare this class, presumably defined in Class name, with a const reference of type Class name, i.e. its own type.

        const - comparison can be made for const objects

        = default; - Use the default implementation, which is comparing all the member variables.

        An alternate more explicit version, which is actually what people recommend:

        auto operator<=>(const ClassName&, const ClassName&) = default;

        if I just want to have less than comparison for example I would:

        This one makes it explicit that you’re comparing two Class name objects.

        if I just want to have less than comparison for example I would:

        auto operator<(const ClassName&, const ClassName&) = default;

        If I need to compare against another class I could define: auto operator<(const ClassName&, const OtherClass&)

    • qaz@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 month ago

      Is there a way to avoid having to write copy and move twice every time yet?

      • flying_gel@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        You mean copy/move constructor and assignment operator?

        Unless you have any special handling the ones generated by the compiler automatically should work just fine. But if you do have to define them for some reason (which is becoming increasingly rare) you would need to define both if you need both copy/move construction and copy/move assignment.

  • Ashelyn@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    33
    ·
    1 month ago

    Is that because it’s that simple, or just that the boilerplate is pre-written in the standard library (or whatever it’s called in rust)?

    • mvirts@lemmy.world
      link
      fedilink
      arrow-up
      46
      ·
      1 month ago

      It’s because people put in the hard work of writing amazing macros instead of baking code reuse into the type system itself 😁 I’m a rust noob and I love the derive macro.

    • Rusty 🦀 Femboy 🏳️‍🌈@lemmy.blahaj.zoneOP
      link
      fedilink
      English
      arrow-up
      29
      ·
      1 month ago

      Yes, it is that simple. In Rust if you have a structure Person and you want to allow testing equality between instances, you just add that bit of code before the struct definition as follows:

      #[derive(PartialEq, Eq)]
      struct Person {
          name: String,
          age: u32,
      }
      

      In Rust, PartialEq and Eq are traits, which are similar to interfaces in Java. Manually implementing the PartialEq trait in this example would be writing code that returns something like a.name == b.name && a.age == b.age. This is pretty simple but with large data structures it can be a lot of boilerplate.

      There also exist other traits such as Clone to allow creating a copy of an instance, Debug for getting a string representation of an object, and PartialOrd and Ord for providing an ordering. Each of these traits can be automatically implemented for a struct by adding #[derive(PartialEq, Eq, Clone, Debug, PartialOrd, Ord)] before it.

    • Dhs92@programming.dev
      link
      fedilink
      arrow-up
      23
      ·
      1 month ago

      Derive macros are a godsend. There’s macros to automatically implement serialization as well. Basically a Trait that can automatically be implemented when derived

      • Dunstabzugshaubitze@feddit.org
        link
        fedilink
        arrow-up
        10
        ·
        1 month ago

        i’ve only read about rust, but is there a way to influence those automatic implementations?

        equality for example could be that somethings literally point to the same thing in memory, or it could be that two structs have only values that are equal to each other

        • Wappen@lemmy.world
          link
          fedilink
          arrow-up
          19
          ·
          1 month ago

          Equality in rust is value equality per default, that’s what these traits are for. If you want to check pointer equality you’d use the std::ptr::eq function to check if two pointers are equal, which is rather rare in practice. You can also implement the PartialEq trait yourself if you need custom equality checks.

          • brisk@aussie.zone
            link
            fedilink
            arrow-up
            1
            ·
            1 month ago

            I worked on software at one point that had at it’s core a number of “modes” that it switched between. It was, at the time, in the process of migrating from enums and switch/case trees to an inheritance based system.

            In practice this meant there was a single instance of “Mode” for each mode which used pointer equality to switch/case on modes like an enum.

            To add a new mode (that did nothing) I think I had to change about 6 different places.

            • Dhs92@programming.dev
              link
              fedilink
              arrow-up
              2
              ·
              1 month ago

              Not really related to the pointer thing, but Rust also has pattern matching based on Enums, as they’re actually sum-types and not just numbers

        • 2xsaiko@discuss.tchncs.de
          link
          fedilink
          arrow-up
          5
          ·
          1 month ago

          Not for the built-in Eq derive macro. But you can write your own derive macros that do allow you to take options, yeah.

    • egerlach
      link
      fedilink
      arrow-up
      9
      ·
      1 month ago

      Ahh, the comment I was looking for

      I would have also accepted: “Haskell did it first.”

  • BaumGeist@lemmy.ml
    link
    fedilink
    arrow-up
    23
    ·
    edit-2
    1 month ago

    Implementing Equality in Haskell:

        deriving (Eq, Ord)
    

    After learning how easy it was to implement functional programming in Rust (it’s almost like the language requires it sometimes), I decided to go back and learn the one I had heard about the most.

    It opened my mind. Rust takes so many cues from Haskell, I don’t even know where to begin. Strong typing, immutable primitives, derived types, Sum types. Iterating and iterables, closures, and pattern matching are big in Haskell.

    I’m not saying Rust uses these because Graydon Hoare wanted a more C-like Haskell, but it is clear it took a lot of elements from the functional paradigm, and the implementations the designers were familiar with had descended through Haskell at some point.

    Also, deriving is not the same as implementing. One is letting the compiler make an educated guess about what you want to compare, the other is telling it specifically what you want to compare. You’re making, coincidentally, a bad comparison.

    • expr@programming.dev
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      1 month ago

      Don’t need the Ord instance for equality, just Eq is sufficient. Ord is for inequalities.

      The point of the post is that most mainstream languages don’t provide a way to automatically derive point-wise equality by value, even though it’s pervasively used everywhere. They instead need IDEs to generate the boilerplate rather than the compiler handling it.

  • akkajdh999@programming.dev
    link
    fedilink
    arrow-up
    21
    ·
    1 month ago

    In Go “==” operator works for everything by default, I like it more:

    type A struct {
    	Name string
    	Quality int
    }
    func main() {
    	var x A
    	var y A
    	fmt.Printf("%v", x == y)
    }
    
    

    (if all you want is to compare all corresponding fields which you usually want)

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      1 month ago

      Yeah, I came to Rust from Scala and Kotlin, where equality is default-implemented (for case class and data class respectively, which is basically all we ever used), so this meme surprised me a bit.

      I do actually like that you can decide a type cannot be compared, because sometimes it really just doesn’t make sense. How would you compare two HTTP clients, for example? But yeah, it certainly is a choice one can disagree with.

  • kazaika@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    1 month ago

    I’d argue that the reason this is so bad in other languages is because of horrible default implementations. Look at tostring in java, getting a somewhat printable object would be easy if the default implementation would use reflection or sth to print the object, but instead it prints hash gibberish no one cares about.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      7
      ·
      1 month ago

      I always hated the implementation for .toString() of Duration. It gives you a string like that: PT8H6M12.345S (not a hash)

      Apparently, it’s an ISO 8601 thing, but what the hell am I supposed to do with that?
      It’s not useful for outputting to end users (which is fair enough), but I don’t even want to write that into a log message.
      I got so used to this just being garbage that I would automatically call .toMillis() and write “ms” after it.

      Well, and not to gush about Rust too much, but I recently learned that its debug string representation is actually really good. As in, it’s better than my Java workaround, because it’ll even do things like printing 1000ms as 1s.
      And that’s just like, oh right, libraries can actually provide a better implementation than what I’ll slap down offhandedly.

      • bleistift2@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        I don’t even want to write that into a log message.

        Why not? It’s a perfectly human readable representation of that duration, just as intended by ISO.

        what the hell am I supposed to do with that?

        Just as an example, we use that format to communicate durations between the frontend and backend.

        • Ephera@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 month ago

          Well, because I’m of a very different opinion about its readability. If you know the format, then sure, you can mostly read it as expected. But our logs are often something that customers or sysadmins will want to read. If it says Retrying in PT5S... in there, they’ll think that’s a bug, rather than a duration.

          And yeah, I almost figured it was for de-/serialization. I guess, that’s something where I disagree with the designers of Java.
          In my opinion, you don’t ever want to rely on the implicit behavior of the language for your serialization needs, but rather want to explicitly write down how you’re serializing. You want to make a conscious decision and document that it’s the ISO 8601 format, so that if you need to hook up another language, you have a chance to use the same format. Or, if you need to change the format, so that you can change the one serialization function, rather than having to find all the places where a .toString() happens.

          Admittedly, the Java devs were between a rock and a hard place, due to them having to implement .toString() and the meaning of .toString() being kind of undefined, i.e. it’s never stated whether this is a format for serialization, for debugging or for displaying to the user. And then I guess, because it didn’t explicitly say “for debugging” on there, they felt it was important to go with a standard format.

  • vext01@lemmy.sdf.org
    link
    fedilink
    arrow-up
    14
    ·
    1 month ago

    But then you realise that the types of 10 constituent fields don’t implement Eq, PartialEq…

  • sik0fewl
    link
    fedilink
    arrow-up
    12
    ·
    1 month ago

    On behalf of Java developers everywhere - thank you Project Lombok!

  • Bogasse@lemmy.ml
    link
    fedilink
    arrow-up
    7
    ·
    1 month ago

    I’m much more impressed by the fact that a type can implement PartialEq and not Eq. Now that’s nice design!

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      1 month ago

      In Python it’s really hard!

      def __eq__(self, other):
          ...
      

      How do you even write those subscripted hyphens???

      • zagaberoo@beehaw.org
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        1 month ago

        If you’ve got a complex and potentially nested object, what does the body of this simple function look like? That’s what they mean.

  • Gonzako@lemmy.world
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    1 month ago

    I’ve only had to implement equality in C# but that didn’t seem that hard of a problem. you just expand the operator = function

      • GetOffMyLan@programming.dev
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        edit-2
        1 month ago

        I just use the HashCode class and compare the results.

        Pretty sure there’s a source generator for it as well nowadays.

      • Deckweiss@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        6
        ·
        edit-2
        1 month ago

        My IDE can do that for me. And it was able to do that pre AI boom. Yes, the code ends up more verbose, but I just collapse it.

        So from a modern dev UX perspective, this shouldn’t be a major difference.

        • porous_grey_matter@lemmy.ml
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          1 month ago

          Even if the tool works perfectly, you have to run it every time you change something. It’s not the end of the world, but it’s still much nicer to just have a macro to derive it at compile time.

        • kazaika@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          1 month ago

          What if youre working with library types? The problem is not not you compare a bunch of fields but that the implementation on those members is most likely bad.

    • copygirl@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 month ago

      Then you should also override Equals(object), GetHashCode, and implement IEquatable<T>.

      Thankfully a lot of the usual boilerplate code can be avoided using a record class or struct:

      public record Person(string Name, uint Age);
      
      • Gonzako@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        Oh well, It does show how little I do have to actually use that. It just hasn’t come up that much

  • Tekhne@sh.itjust.works
    link
    fedilink
    arrow-up
    4
    ·
    1 month ago

    Swift: : Equatable

    (assuming all the members of the struct are themselves equatable, if not the compiler will tell you to implement the == method)