296
Learning to program in rust (programming.dev)
submitted 1 year ago by to c/programmer_humor@programming.dev
58 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 34 points 1 year ago (20 children)

Skill Issue.

For reals though adopting a functional style of programming makes rust extremely pleasant . It’s only when people program in object oriented styles that this gets annoying.

No loops, and no state change make rust devs happy devs.

  • permalink
  • fedilink
  • source
  • hideshow 20 child comments
    •
  • [–] 17 points 1 year ago* (6 children)

    I’m a OOP programmer.

    I wrap everything within Arc<Mutex<>>.

    I’m a happy dev.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 11 points 1 year ago* (5 children)

    I mean yah. That’s what it takes. But like when I try to write code around Arc<_> the performance just tanks in highly concurrent work. Maybe it’s an OOP rust skill issue on my end. Lol.

    Avoiding this leads, for me at least, to happiness and fearless, performant, concurrent work.

    I’m not a huge fan of go-lang but I think they got it right with the don’t communicate by sharing memory thing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago (4 children)

    You mean mutex? Arc allows synchronous read only access by multiple threads, so it's not a performance bottleneck. Locking a mutex would be one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 5 points 1 year ago (2 children)

    Arc is not free, and the extra atomic operations + heap allocations can become a bottleneck.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 1 year ago (12 children)

    I just started learning rust like two days ago and I haven’t had too many issues with OOP so far… is it going to get considerably worse as the complexity of my projects increases?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 8 points 1 year ago (8 children)

    The thing with OOP, particularly how it's used in GCed languages, is that it's all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it's modified in asynchronous code.

    Rust has quite the opposite mindset. It's all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

    But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

    Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
    Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

    ¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don't need them.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 1 year ago

    It pushes your code to be very tree-shaped

    This is basically where my learning took me. I had to develop this notion that there was a preferred directionality to ownership and data flow, like "grain" in a piece of wood. Everything is easier if you go with the grain. "Tree-shaped" works too, since it basically is the call graph of a (single threaded) program.

    The point where I realized all this was when I tried to do a very Python/JS-brained thing: return a closure from a function. The moment you try to "curry" values into the closure, you have to "move" them to solve for ownership, lest you bring timelines into the picture. Which isn't always what you want in a generic and reusable function. And sure enough, the standard lib and other popular libraries want you to pass a closure to functions instead.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago (6 children)

    OOP also has object ownership hierarchy structures. Which object owns which other object, is a question always worth answering.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago (5 children)

    Hmm, not sure, if I've heard of it. I'm guessing, we're not talking about simply drawing a UML class diagram...? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 1 year ago* (4 children)

    Yes, pretty much like UML diagrams. Who is responsible for allocating memory and freeing it.

    Languages like Swift, Objective-C, C++ have features that mean you don’t need to do this by hand. But you have to tell the compiler if you want to keep and object around and who owns it.

    See this article on Objective-C to see the different ways to manage memory this language supports.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn't needed, to Rust where well-defined ownership is enforced by the language.

    So, I wasn't aware that ownership is even as concrete of a thing in other languages...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago (2 children)

    Oh you need this in garbage collected languages too, once you run into memory use issues. GC languages are notorious for being wasteful with memory, even when working correctly.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    Not if you never get your application into production...

    Insert *tips head* GIF here.

    I wish this was as much of a joke as I'm pretending. It's so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.

    For most of the development lifecycle of a GCed project, you're gonna ignore memory usage. And if you're lucky, it can be 'solved' by just plonking down a thiccer piece of hardware...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 year ago

    Worse in the sense of more errors, sure, but as you go you’ll pick up more of the rust patterns of thinking and imo it’s very worth it. It’s an odd blend and can be a bit verbose but I definitely prefer it to a pure OO or pure functional style language personally

  • permalink
  • fedilink
  • source
  • parent