• wim@lemmy.sdf.org
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    That’s a whole different thing to me. That’s not async, that’s channels and multithreading.

    I do that in Rust as well with mcsp channels and it’s been fine.

    It’s the async/await bit that I find incredibly akward all the time.

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      Channels and multithreading are a solution to async problems. Instead of a keyword trying to abstract away the async, you use a mechanism for communicating between coroutines. You can run Go with a single execution thread and still get benefits from goroutines and channels. In fact, Go didn’t turn on multithreading until 1.5.

      Go solves async with goroutines and channels, not with an async keyword. The runtime is pretty heavy and steps in when standard library functions would block. In other words, it’s async by default since blocking IO causes another goroutines to execute.

      • Júlio Gardona@mastodon.social
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        @sugar_in_your_tea @wim
        go channels and goroutines are very good and easy to work, but thei cant acquire the performance and security of #tokio. You can write good code and solutions with goroutines, but there are limitations. #Rust async is a bit more difficult to do, but its not so or too complicated or dificult, and you will choose between the two languages by kind of problems you want to solve.

        • sugar_in_your_tea@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Yes, there’s absolutely a lot of good reasons to use Rust over Go, even for heavily async tasks, I’m merely saying that Go supporting channels in the language makes it a lot easier to use for async tasks. There’s one proper way to send data between concurrent contexts, and that’s a channel, so it gets used a ton in library code.

          Rust could get a lot of that benefit by including channels in the standard library. We could still keep the async reactor code out of the standard library, but we’d need trait definitions there so the channels could hook into them.

          I personally think the Rust standard library should ship a complete async solution, with core bits being overridable (like with memory allocation), which would make it a lot easier to write clean async logic. I think the standard library should be single threaded, but be multi-threaded compatible, and then allow third party libraries to provide the multi-threaded capability.