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
        link
        fedilink
        arrow-up
        1
        ·
        2 days ago

        Keep in mind that it doesn’t remove tokio from the stack tho. Don’t use this to try to improve compilation time

        • flamingos-cant (hopepunk arc)@feddit.uk
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 days ago

          I know, I read the description. It just looks like a nicer syntax around setting up a tokio runtime and sending code between runtimes. It’d still be nice to have a non-tokio options so stuff could be single threaded.

          • RustyNova@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            2 days ago

            A lot of the time it’s not about options. It’s about not messing up the async pattern.

            If you have something that either:

            • requires a lot of CPU time
            • requires to run permanently, independently to the caller’s future polling. Then you can spawn it on a global tokio executor.

            If not, just use future polling tricks like the futures::join!() macro or a stream with .buffered(). It won’t be slower. The bottle neck is IO. Not the program.

            Personally I even try to replace the heavy reqwest library with ureq + blocking, and it works perfectly and compiles faster (you can see that in the api_bindium crate)