I’ve been programming for decades, though usually for myself, not as a profession. My current go-to language is Python, but I’m thinking of learning either Swift (I’m currently on the Apple ecosystem), or Rust. Which one do you think will be the best in terms of machine learning support in a couple of years and how easy is it to build MacOS/ iOS apps on Rust?

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

    I’m not a performance expert by any means, but…it seems like the bit about there being “no situation, ever” in which a garbage collector that “worked just as well as in any other language” outperformed reference-counting GC. The things I’ve read about garbage collection generally indicate that a well-tuned garbage collector can be fast but nondeterministic, whereas reference-counting is deterministic but generally not faster on average. If Apple never invested significant resources in its GC, is it possible it just never performed as well as D’s, Java’s, or Go’s?

    • abhibeckert@lemmy.world
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Check out this interview with Chris Lattner — one of the world’s best compiler engineers and the founder of not only the Swift language but also LLVM which backs many other languages (including Rust). It’s a high level and easily understood discussion (you don’t need to be a language expert) but it also goes into quite a few technical details.

      https://atp.fm/205-chris-lattner-interview-transcript#gc

      Chris briefly talks about the problems in the Apple GC implementation, but quickly moves onto comparing ARC to the best GC implementations in other languages. The fact is they could have easily fixed the flaws in their GC implementation but there just wasn’t any reason to. ARC is clearly better.

      Apple’s GC and ARC implementations were both implemented at about the same time, and when ARC was immature there were situations where GC worked better. But as ARC matured those advantages vanished.

      Note: that interview is six years old now - when Swift was a brand new language. They’ve don a ton of work on ARC since then and made it even better than it was, while GC was already mature and about as good as it’s ever going to et at the time. The reality is garbage collection just doesn’t work well for a lot of situations, which is why low level languages (like Rust) don’t have a “proper” garbage collector. Arc doesn’t have those limitations. The worst possible scenario is every now and then you need to give the compiler a hints to tell it to do something other than the default - but even that is rare.

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

        Thanks for sharing the interview with Lattner; that was quite interesting.

        I agree with everything he said. However, I think you’re either misinterpreting or glossing over the actual performance question. Lattner said:

        The performance side of things I think is still up in the air because ARC certainly does introduce overhead. Some of that’s unavoidable, at least without lots of annotations in your code, but also I think that ARC is not done yet. A ton of energy’s been poured into research for garbage collection… That work really hasn’t been done for ARC yet, so really, I think there’s still a a big future ahead.

        That’s optimistic, but certainly not the same as saying there are no scenarios in which GC has performance wins.