7 ms·

You can always just do let no_async = block_on(something_async);

• kangalioo 4y ago
  I'd instinctively worry about overhead there Are there benchmarks comparing sync http libraries with block_on-wrapped async http libraries?
  • bongobingo1 4y ago
    Is the overhead going to matter if your content to block anyway? Surely any threading etc constructs are tiny compared to wire time, etc.
    • ibraheemdev 4y ago
      Blocking I/O+threads can actually scale very well now, and with block_on you get the worst of both worlds, but yeah, I agree that most people are probably fine with it.
      • vbezhenar 4y ago
        Most people fine with python. Those who come to Rust are not fine with overhead.
        • mcronce 4y ago
          This assumes that people only use Rust for the performance. I don't think that's strictly true. 95% of what I write isn't performance-critical or even, really, performance-relevant. I still choose Rust for the vast majority of projects for ergonomic and correctness reasons.
          • adwn 4y ago
            You're spot on. I recently chose Rust over Python for a very small program which reads a JSON (or Hjson) file, does some checking and processing, and writes the results to a different JSON file, because Rust has serde, proper static type checking, algebraic data types, and other features that made it more productive than Python (!!!) for that specific use case. Performance wasn't even a consideration, I made judicious use of clone() and run it in debug mode.
            • dagmx 4y ago
              Serde is such an awesome library. Having to decode serialized data in the other languages (Swift, C++, Python) I write is such a bear after using serde. Swift comes closest with codable/decodable but it's often still lacking the ergonomics of serde, especially the attribute options per field
        • dagmx 4y ago
          Some people who come to rest may not be fine with it. A lot of people come to rust for other reasons, like compile time safety checks etc... But most importantly, the delta between the performance of block_on and not, versus block_on and Python are massively different. You can write inefficient rust and still have a huge win over Python.
  • ibraheemdev 4y ago
    > I'd instinctively worry about overhead there Yeah, one of the nice things about blocking I/O is that you can perform it with a single syscall. With block_on(async_io), you're now dealing with registration with a reactor, polling epoll, and extra syscalls for each I/O operation. Not to mention the overhead of running the state-machine as opposed to line by line.