3 ms·

Much of futures' functionality is now in the standard library (core::future). Tokio is quite heavy, and I don't like it: smol is a better "futures standard libr

Much of futures' functionality is now in the standard library (core::future). Tokio is quite heavy, and I don't like it: smol is a better "futures standard library", in my opinion. There's async-compat if you need to interop with tokio, so I never have to write glue code (even if I'd rather not have a tokio runtime).

apatheticonion 1y ago
I'm with you on Tokio. I have tried alternative runtimes however the constant interop issues is a very poor developer experience, and difficult to justify when other developers are contributing. Using hyper with streamed http responses (which depends on tokio::duplex). You're already depending on the futures and async-compat crates to adapt tokio futures. I don't even know how hyper could be set up to use another async backend or what performance penalty another adapter layer would have on performance. > Much of futures' functionality is now in the standard library (core::future) In that case, I would love to see Tokio move to depend on the stdlib interfaces rather than exporting their own lookalikes. That way runtimes can be interchangeable. I guess the same goes for utils like task::sleep, channels and fs interactions.
rendaw 1y ago
Heavy in terms of lines of code, or overhead? Where does that come from? Do you have some numbers?
- lkirkwood 1y ago
  Tokio is fast, but it's huge! Check the size of any library or binary that includes tokio with even minimal features, let alone their recommended default feature set which comes with a complimentary kitchen sink.
  - wizzwizz4 1y ago
    If it were dynamically-linked, I'd be more okay with it – but it's statically linked, so every process in memory has its own copy, with slightly different layouts of various structures.
    - rendaw 1y ago
      Does everything get included though? I'd assume unused stuff is compiled out.
      - wizzwizz4 1y ago
        Given how dynamic an async executor is, there's a lot that doesn't get compiled out. Rust doesn't seem to optimise well across dyn boundaries. (I haven't bothered investigating: I usually just rewrite my program to work better, because if I'm encountering this case there's probably other stuff wrong too.)

apatheticonion 1y ago

I'm with you on Tokio. I have tried alternative runtimes however the constant interop issues is a very poor developer experience, and difficult to justify when other developers are contributing. Using hyper with streamed http responses (which depends on tokio::duplex). You're already depending on the futures and async-compat crates to adapt tokio futures. I don't even know how hyper could be set up to use another async backend or what performance penalty another adapter layer would have on performance. > Much of futures' functionality is now in the standard library (core::future) In that case, I would love to see Tokio move to depend on the stdlib interfaces rather than exporting their own lookalikes. That way runtimes can be interchangeable. I guess the same goes for utils like task::sleep, channels and fs interactions.

rendaw 1y ago

Heavy in terms of lines of code, or overhead? Where does that come from? Do you have some numbers?

lkirkwood 1y ago
Tokio is fast, but it's huge! Check the size of any library or binary that includes tokio with even minimal features, let alone their recommended default feature set which comes with a complimentary kitchen sink.
- wizzwizz4 1y ago
  If it were dynamically-linked, I'd be more okay with it – but it's statically linked, so every process in memory has its own copy, with slightly different layouts of various structures.
  - rendaw 1y ago
    Does everything get included though? I'd assume unused stuff is compiled out.
    - wizzwizz4 1y ago
      Given how dynamic an async executor is, there's a lot that doesn't get compiled out. Rust doesn't seem to optimise well across dyn boundaries. (I haven't bothered investigating: I usually just rewrite my program to work better, because if I'm encountering this case there's probably other stuff wrong too.)