3 ms·

> I fear the Rust world that overuses macros I share this fear. Rust macros are _amazing_ and indispensable but their overuse makes understanding third party c

> I fear the Rust world that overuses macros I share this fear. Rust macros are _amazing_ and indispensable but their overuse makes understanding third party code extremely difficult. There are cases where macros are used to avoid repetition, I feel like code generation makes more sense here, where crates publish expanded syntax. My other fear is the fragmentation of standard interfaces. AsyncRead and AsyncWrite are prime examples. If you build an http server you end up using tokio's AsyncRead AND futures AsyncRead - then a bunch of glue code to make them compatible with each other. I'd love to see the standard library reinforced with crates that are basically default installs for their use cases. Tokio, futures, http, httpparse, maybe a variant of anyhow.

wizzwizz4 1y ago
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.)

wizzwizz4 1y ago

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.)