Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can someone tell me why tokio is so damn big and full of transitive dependencies :D?


You could also say that Tokio has a large and mature ecosystem surrounding it.


How big is it?


Here are the compiled-in dependencies:

    $ cargo tree -e no-dev,no-build --no-dedupe -p tokio

    tokio v1.0.0
    ├── bytes v1.0.0
    ├── libc v0.2.81
    ├── memchr v2.3.4
    ├── mio v0.7.6
    │   ├── libc v0.2.81
    │   └── log v0.4.11
    │       └── cfg-if v0.1.10
    ├── num_cpus v1.13.0
    │   └── libc v0.2.81
    ├── once_cell v1.5.2
    ├── parking_lot v0.11.1
    │   ├── instant v0.1.9
    │   │   └── cfg-if v1.0.0
    │   ├── lock_api v0.4.2
    │   │   └── scopeguard v1.1.0
    │   └── parking_lot_core v0.8.2
    │       ├── cfg-if v1.0.0
    │       ├── instant v0.1.9 (*)
    │       ├── libc v0.2.81
    │       └── smallvec v1.4.2
    ├── pin-project-lite v0.2.0
    └── signal-hook-registry v1.3.0
        └── libc v0.2.81
There are a lot more dependencies that are used only for the build scripts (build-dependencies) or for running the tests, examples, and benchmarks (dev-dependencies). None of those dependencies cause any additional code to wind up in your binaries when your project depends on tokio.

PS, I think there's a bug in "cargo tree"... the command above actually prints out only one line ("pin-project"). I had to remove the "-p tokio" and then copy-and-paste out the relevant section.


Most of that is parking_lot, which is an optional feature not even included in the full feature.





Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: