tokio VS futures-rs

That's it. Everything else — async/await, actors, work-stealing executors, lock-free data structures — lives in the ecosystem (tokio, rayon, crossbeam, actix, etc.).

Building LlamaStash brought me back to a lot of that, but the ground has shifted. ratatui (the maintained fork of tui-rs) is a real, polished framework now. tokio makes async daemons boring in a good way. hyper gives you a respectable HTTP server in a few hundred lines. crossterm handles the cross-platform terminal mess. sysinfo covers host metrics. The pieces are all there and you have LLMs to help you speed up everything to 10x.

The async ecosystem has matured to the point where this is actually enjoyable to build now. Tokio is the async runtime most production Rust services are built on, and Axum gives you an ergonomic HTTP layer that won’t make you miss Go’s simplicity quite as much as you’d expect.

Tokio — Async runtime para Rust — Runtime más usado para servicios de red y concurrencia en Rust.

Understanding the internals won't change how you write async Rust day to day, but it changes how you think about it. That mental model helps when you find you're on one of Rust's sharp edges. If you want to go deeper, the tokio source, this blog post by Priyanka Yadav, and Jon Gjengset's async Rust series are the best next steps.

In fastjson-api, I leveraged Rust’s async capabilities with tokio to handle thousands of simultaneous connections efficiently. The project demonstrates how Rust’s zero-cost abstractions can lead to a lightweight, high-throughput API server.

https://github.com/tokio-rs/tokio/pull/7622

The tests do not appear to simulate the queue in Loom, which would be a very, very good idea.

This stuff is _hard_, and I almost certainly made a mistake in the above. In practice, the queue is probably fine to use, but I wouldn't be shocked if there's a heisenbug lurking in this codebase that manifests something like: it all works fine now, but in the next LLVM version an optimization pass which breaks it on ARM, and after that the queue yield duplicate values in a busy loop every few million reads which is only triggered in release mode on Graviton processors.

Or something. Like I said, this stuff is _hard_. I wrote a very detailed simulator for the Rust/C++ memory model, have implemented dozens of lockless algorithms, and I still make a mistake every time I go to write code. You need to simulate it with something like Loom to have any hope of a robust implementation.

For anyone interested in learning about Rust's memory model, I can't recommend enough Rust Atomics and Locks:

https://marabos.nl/atomics/

Asynchronous Processing: With the power of tokio, the server handles DNS queries asynchronously, with no blocking, improving scalability and latency.

It's definitely a bit contrived, but to me it's also emblematic of the issues with async Rust.

The note on mpsc::Sender::send losing the message on drop [1] was actually added by me [2], after I wrote the Oxide RFD on cancellations [3] that this talk is a distilled form of. So even the great folks on the Tokio project hadn't considered this particular landmine.

[1] https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.h...

[2] https://github.com/tokio-rs/tokio/pull/5947

[3] https://rfd.shared.oxide.computer/rfd/0400

Asynchronous programming has seen considerable adoption, and Rust's Tokio runtime provides an excellent framework for writing asynchronous code. Utilizing async/await syntax in Rust allows for efficient concurrent execution in I/O-bound applications.

Before anything, we need to add kube-rs controller runtime to our project. We will also add the "thiserror" to make it easier to generate the errors, and "futures" as a required dependency

So this is actually better than true fairness (true fairness would lead to deadlock if a sender is forgotten). It is a pity that the there does not seem to be resources that document this design. There is this old thread where Carl provides some background, but I found it personally a bit hard to follow.

Is this still true after it switched to using FuturesOrdered?

Done.

You can use Streams, which are the async version of Iterators; They aren't stable yet, so you'll have to use a crate such as futures.

futures

For traits, like AsyncRead and AsyncWrite, go with the futures crate.

Here is the PR: https://github.com/rust-lang/futures-rs/pull/2551

Yield = wake the `waker_ref`. Avoiding the yield would be clone().wake().

That said, "poll immediately" isn't actually a thing nor was it ever a thing except in incorrect implementations.

Rust lacks an implementation of ReactiveX. futures/futures-signals seems to be the the ecosystem equivalent but I'm sure there'd be a lot of interest in an actual implementation.

The opposite problem exists as well. Many types are actually unwind safe, but do not get the autotrait. In that case authors would have to manually declare them UnwindSafe. Because this is rarely done, having an API with a trait bound T: UnwindSafe is rarely viable in terms of ergonomics. It now obliges client code to wrap all calls to your API in AssertUnwindSafe which, if they use types from third party libraries, obliges them to assert this is fine. example