I'm working on a falling sand physics-powered, 2d block-based open-world survival crafting game with spells instead of weapons and tools.
I'm currently using bevy_ecs (not bevy itself) and Vulkano (Vulkan rust library), SDL2 for windowing and fmod for audio. Developing on Linux but testing and building on Windows every now and then.
I've been running a Terraria server since 2012, and have had a lot of experience in C# working with Terraria's netcode and Terraria internals (via decompiling and IL patching), so decided it was time to try make something of my own.
I didn't know any engines, but I had previously used SDL2 for smaller things. We started using Rust at work (not game dev related) and I had used Rust a few times for personal projects. I got really interested in some of the functional programming concepts from languages like Ocaml and Haskell, so I decided I would make the game in Rust, despite that it may not be the most popular path.
This won't really help you consider another runtime specifically, but it is an instance of not choosing Tokio.
When I was benchmarking with Tokio I found it had quite a difference (higher cpu usage) to other options I was exploring. My specific use-case was an async single-threaded application which does mostly network io + timers. I would be interested to see how Tokio fairs today (I tested it over a year ago) and quite possibly any advice or tips in writing efficient code with it. My benchmark was send/recv with a UDP socket and print out stats in a timer (that's the core idea of what I needed to use it with). Comparing both CPU usage and maximum throughput.
For normal async, I would probably still reach for Tokio, but the use case I was looking at was very much specific to what I was working on at my job (still am), and lower CPU usage as well as higher throughput is what we needed. We ended up building a small internal runtime that uses mio, it was also fun to implement. In the benchmarks we ran, it used less CPU % than Tokio, and achieved higher throughput, by enough that we thought it was worth continuing to use our internal one.