• fmstrat@lemmy.nowsci.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    4 months 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.

  • r00ty@kbin.life
    link
    fedilink
    arrow-up
    0
    ·
    4 months 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
      1
      ·
      4 months 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.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      4 months 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.

  • flying_gel@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 months 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
      1
      ·
      4 months 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
        1
        ·
        4 months 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…

  • Ashelyn@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    0
    ·
    4 months 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)?

    • Rusty 🦀 Femboy 🏳️‍🌈@lemmy.blahaj.zoneOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months 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.