BTW I think some anti-Rust people are more annoying than the worst Rust evangelists - seen some of them calling people not using Rust as “murderers”, because “memory leakage can kill at the right time” - but that’s due to them being evangelists to right-wing politics.

  • RustyNova@lemmy.world
    19·
    16 hours ago

    Tbh the borrow checker isn’t a problem for 75% of cases. If you actually need the performance/memory optimization then yes you will have to deal with it… Otherwise just .clone()

    And if you find the borrow checker annoying in async rust, that’s mostly a tokio issue. Look into smol-rs as it offers alternatives

    If you want real cons…

    • Compile times
    • easy build time arbitrary code execution
    • trait bounds spaghetti
    • flamingos-cant (hopepunk arc)@feddit.ukEnglish
      2·
      6 hours ago

      And if you find the borrow checker annoying in async rust, that’s mostly a tokio issue. Look into smol-rs as it offers alternatives

      This is great until you want to use a library which is tokio exclusive, which is most of them.

        • cjk@discuss.tchncs.de
          3·
          8 hours ago

          When people say “async is viral” in Rust, they mean that once you make one function async, that change tends to ripple through the rest of your code. Any function that calls it usually has to become async as well so it can await the result. In turn, the callers of those functions often need to become async too.

          This propagation can continue all the way up the call stack until you reach your application’s entry point. The main exception is when you introduce an explicit synchronous-to-asynchronous boundary, such as by using block_on, which drives the future to completion without requiring the caller itself to be async.

          • RustyNova@lemmy.world
            3·
            5 hours ago

            Yeah but it’s not really a problem with rust but how the language pattern is made. It’s the same in JavaScript/typescript, and Python IIRC