A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ... (by tokio-rs)

Tokio Alternatives

Similar projects and alternatives to tokio
  • radius-rs

    An async/await native implementation of the RADIUS server and client for Rust.

  • rust

    Empowering everyone to build reliable and efficient software.

  • tauri

    Build smaller, faster, and more secure desktop applications with a web frontend.

  • hyper

    An HTTP library for Rust

  • reqwest

    An easy and powerful Rust HTTP Client

  • tide

    Fast and friendly HTTP server framework for async Rust

  • async-std

    Async version of the Rust standard library

  • smol

    A small and fast async runtime for Rust

  • async-std-hyper

    How to run Hyper on async-std

  • 996.ICU

    Repo for counting stars and contributing. Press F to pay respect to glorious developers.

  • alacritty

    A cross-platform, OpenGL terminal emulator.

  • MeiliSearch

    Lightning Fast, Ultra Relevant, and Typo-Tolerant Search Engine

  • wasmer

    🚀 The leading WebAssembly Runtime supporting WASI and Emscripten

  • bevy

    A refreshingly simple data-driven game engine built in Rust

  • ruffle

    A Flash Player emulator written in Rust

  • rust-analyzer

    An experimental Rust compiler front-end for IDEs

  • rfcs

    RFCs for changes to Rust

  • ggez

    Rust library to create a Good Game Easily

  • rust-blog

    Educational blog posts for Rust beginners

  • freeradius-server

    FreeRADIUS - A multi-protocol policy server.

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better alternative or higher similarity.


Posts where tokio has been mentioned. We have used some of these posts to build our list of alternatives and similar projects.
  • Blog post: Future::join and const-eval | 2021-01-17
    Not sure if you know, but there already had been work on bringing TaskGroup (which is kind of a trio nursery, or a Kotlin CoroutineScope) to Rust here and here. There however had been some trickiness detected in the interaction with Rusts cancellation and panic behavior for async fns, which make this harder than in the other languages. Anyway, if you are interested look into the associated threads on Zulip or talk to me. | 2021-01-17
    This is not about the task panicing or aborting. It's about the parent task (scope owner) panicing or abort - e.g. because it's inside a select!. In that case the child tasks are now unowned, and it's tricky to find a good solution on what you do with them. The same would totally apply to async-std or any other current async rust runtime. The unfortunately rather long discussion in 1879 describes it. The whole design and implementation for this had been fairly agnostic to any runtime. All it needs is a spawn function and join handles. Those were hardcoded to tokios, but that doesn't mean it couldn't be either generalized or ported somewhere else. But the same set of challenges will apply.
  • How to migrate method 'next' from tokio 0.3 to tokio 1.0? | 2021-01-07
    The direct answer to your question is found here.
  • missing stream impls from tokio-stream | 2020-12-24
    For now you will have to either manually implement Stream on a wrapper or use async-stream. There's an example of a manually implemented stream here. | 2020-12-24
    There's an example here. There's another example here.
  • One async lib to rule them all | 2020-12-23
  • Tokio, the async runtime for Rust, hits 1.0 | 2020-12-23
    Here is an example:

    You do have to write a ~50 loc compat layer. However, most of the compat layer is due to the fact that tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures crate, which may change in the future [0]. After that, you just have to implement `hyper::Executor` for async-std's `spawn`, and `hyper::Accept` for async-std's `TcpListener`.

    Of course, it is not as generic as `Future`, but it is relatively simple. As @steveklabnik mentioned:

    > There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.

    [0]: | 2020-12-23 | 2020-12-23
    Yes, it is a concern, but Tokio people decided transition can happen without breaking changes hence it does not block 1.0. See for details.
  • Tokio 1.0.0 Released | 2020-12-23
  • Tokio 1.0.0 has been released! | 2020-12-23 | 2020-12-23
    remove tokio::prelude (#3299) | 2020-12-23
    There are no std traits. See for the planning that went into this release regarding this. In particular Where should the traits be defined? And subsequent sections.
  • Released radius-rs: an async/await native RADIUS implementation for Rust | 2020-12-13
    The feature of this implementation is async/await native functions powered by tokio. And this implementation and design is based on layeh/radius, this is a RADIUS implementation for golang, so it can generate the Rust code to make the RADIUS applications by giving the dictionary files of FreeRADIUS.
  • Rusticles #20 - Wed Nov 18 2020 | 2020-11-17
    tokio-rs/tokio (Rust): A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...


Basic tokio repo stats
6 days ago

tokio-rs/tokio is an open source project licensed under MIT License which is an OSI approved license.