Assume mainstream adoption as used by around 7% of all github projects

Personally, I’d like to see Nim get that growth.

  • zygo_histo_morpheus@programming.dev
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    You are absolutely correct that rusts safety features don’t extend to memory leaks, but it’s still better than most garbage collected languages unless you abuse Rc or something, and it does give you quite fine-grained controll over lifetimes, copying and allocations on the heap which in practice means that rust is fairly good about memory leakages compared to most languages.

    • IAm_A_Complete_Idiot@sh.itjust.works
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      1 year ago

      How would rust fare any better then a tracing GC? Realistically I’d expect them to use more memory, and also have worse determinism in memory management - but I fail to really see a case where rust would prevent memory leaks and GC languages wouldn’t.

      • zygo_histo_morpheus@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        If you just Rc everything (which I’d count as “abusing Rc”) Rust is significantly worse than a language with a good GC. The good thing about Rust is that it forces you to aknowledge and consider the lifetimes of objects. By default things are allocated on the stack, but if you make something global or dynamically handled (e.g. through Rc) you have to do so explicitly. In Rust the compiler has greater compile time information about when things can be freed which means that you need less runtime overhead to check things and if you want to minimize the amount of potentially long-lived objects you can more easily see how long objects might live by reading the code as well as get help by the compiler to determine if a lifetime-based refactoring is sound or not.