The State of Async Rust: Runtimes

The State of Async Rust: Runtimes

Any time we reach for an Arc or a Mutex in Rust, it's essential to pause and consider the future implications of that decision. Choosing to use Arc or Mutex might indicate that our design hasn't fully embraced the ownership and borrowing principles that Rust emphasizes. It's worth reevaluating whether the shared state is truly necessary or if there's an alternative design that could minimize or eliminate the need for shared mutable state.

However, one challenge is that Tokio, a popular asynchronous runtime for Rust, imposes a certain design on us. It doesn't give us the freedom to make our own choices. This can limit our ability to fully embrace Rust's principles and find more efficient ways of handling concurrency.

On a related note, V8 isolates have their own pros and cons. While they provide good isolation in terms of security and resources, they also require reinventing various components to achieve this level of isolation. For example, CloudFlare or any other entity should never run multiple isolates in the same operating system (OS) process. Instead, isolates should be sandboxed in separate processes to ensure better security. Chrome already sandboxes isolates in isolated processes.

Process isolation, although slightly heavier in terms of resource usage, provides better security. By forking processes, we can take advantage of techniques like cgroups to restrict resources and namespaces to limit network access. Deno Deploy, for instance, follows this approach. It forks processes to achieve isolation and utilizes OS-level sandboxing to enhance security.

Interestingly, once we've forked a process, we're not far off from running something like Firecracker. Firecracker, which we use at Fly.io, offers hardware virtualization and is remarkably fast. However, it requires running on bare metal to fully utilize its benefits.

In the future, it's likely that these different approaches will converge. V8 isolates will eventually run in isolated processes that can leverage hardware virtualization. Ideally, they should already run in isolated processes that take advantage of OS-level sandboxing. Simultaneously, users of Firecracker, like us, will be able to optimize cold starts, reduce memory usage, and more. The natural endpoint is to run V8 isolates or WebAssembly (wasm) runtimes in lightweight virtual machines (VM).

To make the most of these developments, here are three actionable pieces of advice:

1. Embrace Rust's ownership and borrowing principles: Instead of immediately resorting to shared mutable state with Arc or Mutex, explore alternative designs that minimize or eliminate the need for it. This will align your code with Rust's core principles and lead to more efficient and safer code.

2. Consider process isolation: When working with V8 isolates or other similar technologies, evaluate whether running them in isolated processes is a better approach. Process isolation can provide better security and resource restrictions, enhancing the overall reliability of your application.

3. Explore lightweight VMs: As the trend suggests, running V8 isolates or wasm runtimes in lightweight VMs could become the standard. Keep an eye on developments in this area and experiment with lightweight VMs like Firecracker to optimize your application's performance.

In conclusion, the state of async Rust runtimes is evolving. While Tokio may limit our design choices, it's important to consider alternatives and strive for code that aligns with Rust's principles. V8 isolates offer isolation but require careful implementation, and process isolation can bring additional security benefits. Looking ahead, lightweight VMs may become the future for running V8 isolates and wasm runtimes. By keeping these considerations in mind and taking actionable steps, developers can stay ahead in the Rust ecosystem and build more efficient and secure applications.