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
[–] 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
    •