• kazaika@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    4 hours 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.

  • r00ty@kbin.life
    link
    fedilink
    arrow-up
    42
    ·
    14 hours 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
      7
      ·
      12 hours 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
        10
        ·
        edit-2
        12 hours 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
          1
          ·
          4 hours 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)?])
          }
          
  • akkajdh999@programming.dev
    link
    fedilink
    arrow-up
    13
    ·
    12 hours 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)

  • Bogasse@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    8 hours ago

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

  • flying_gel@lemmy.world
    link
    fedilink
    arrow-up
    24
    ·
    16 hours 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;

    • qaz@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      5 hours ago

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

    • xor@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      26
      arrow-down
      1
      ·
      15 hours ago

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

      • tetris11@lemmy.ml
        link
        fedilink
        arrow-up
        10
        ·
        12 hours 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.

  • Ashelyn@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    28
    ·
    17 hours 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
      38
      ·
      17 hours 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
      21
      ·
      16 hours 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
      18
      ·
      17 hours 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
        8
        ·
        16 hours 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
          13
          ·
          16 hours 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.

        • 2xsaiko@discuss.tchncs.de
          link
          fedilink
          arrow-up
          4
          ·
          12 hours 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.

  • vext01@lemmy.sdf.org
    link
    fedilink
    arrow-up
    11
    ·
    15 hours ago

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

    • ReversalHatchery@beehaw.org
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      2
      ·
      10 hours ago

      not the IDE, its the compiler. this is also not some AI shit, in many cases (not all) the compiler can actually figure out how to do this, because it’s not hard, it would just be a lot of boilerplate if written manually.

      • PeriodicallyPedantic@lemmy.ca
        link
        fedilink
        arrow-up
        2
        ·
        9 hours ago

        Why did you even bring up AI? IDEs have been able to generate equality functions for decades without AI.

        It’s kinda neat to have this defined directly in the language so that compilers can implement it, but creating equality function is so low effort that this doesn’t really seem like a big deal.

        Like, you define the members in a class, then you tell your IDE to generate getters, constructor, equals, hashcode, etc all in like 5 seconds.
        I like it, it’s nice when the language itself defines reasonable defaults for things, but realistically you’re saving yourself a few seconds of effort.

        • Mia@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          5
          ·
          9 hours ago

          Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc…

          The Rust way’s just a lot cleaner imo.

        • words_number@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          7 hours ago

          Isn’t it obvious? More code to skim, scroll over and maintain if something changes. If you add a struct field, your manual EQ implementation still compiles and seems to work but is wrong and will lead to bugs. Yes, solving this for 99,999% of cases with an attribute is just far superior and does make a difference (while keeping it easy to manually implement it if needed). Hash and Ord and some other traits can be implemented in a similar fashion btw…

  • Gonzako@lemmy.world
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    17 hours 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
        14 hours 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
        5
        ·
        edit-2
        14 hours 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
          2
          arrow-down
          1
          ·
          14 hours 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.

    • copygirl@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      5
      ·
      14 hours 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
        ·
        10 hours ago

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