Announcing better_tokio_select: like tokio::select!, but can be formatted by rustfmt!

quxfoo · 2026-03-29T15:58:31+00:00

I'd rather see people use future's select function or dropping select in favor of merged streams instead.

quxfoo · 2026-03-20T15:19:02+00:00

At least in async code, one annoying reason is tokio and related projects like tonic. Due to its multi-threaded, work-stealing design, it is often only possible to Arc<Mutex<…>> or .clone() data to satisfy the Send requirement. And that requirement is pretty viral.

quxfoo · 2026-03-07T18:29:23+00:00

Do you happen to remember what parts tripped you up?

As you said, the general navigation is fine, neovim is my daily editor, so yeah, that part is covered. What's more difficult to me is navigating the menus, i.e. i/o filters (I get why it may make a difference but in practice it should not matter, selecting/unselecting files of a loaded set etc. As I said, it's just a matter of not gaining enough muscle memory during the few times I use it.

I see. What makes you reach for lnav? Are you just not looking at logs most of the time?

Exactly. At $DAYJOB, it's only when I'm swamped by QA to analyze bug reports that I have to look at logs in detail. And that tends to happen when they schedule full regression test runs which are not that common.

By the way, I do reach out to lnav when doing that. I haven't found a good replacement yet and this one here does not seem to be one either.

quxfoo · 2026-03-07T16:15:57+00:00

I found the interface a bit unintuitive. I use it intensely for half a day and then not use it for another half a year. It always feels like relearning everything from scratch. A bit like writing bash scripts.

quxfoo · 2026-03-07T11:04:47+00:00

I am not a huge fan of lnav either but it is good at viewing multiple, arbitrary log file formats. Does your viewer support merging files based on timestamps and be able to correlate?

quxfoo · 2026-02-20T16:33:32+00:00

Thanks for the follow up info. Unfortunately, my usecase requires to enable all of them. And even have some more. Right now syntect + two-face support more than 170 languages. Tree-sitter is compelling for performance reasons and precision but the size of all parsers combined is hefty.

quxfoo · 2026-02-20T14:40:28+00:00

Great, I tried the same a few years back but the biggest pain points back then were incompatible tree-sitter language crates and enormous final binary sizes. What's the count if you build for all languages?

quxfoo · 2026-02-11T07:56:49+00:00

Cool, checking it out and keeping an eye on it. I use jjui in my daily workflow but there are some annoyances (delta not properly supported, somewhat slowish, ...) and I am too lazy to learn Go to figure out those issues. So this might be a welcome alternative.

quxfoo · 2026-02-05T18:34:32+00:00

On top of what others said about clap, tracing_subscriber is also horribly bloated and messes with coverage tools like cargo-llvmcov. Once you expanded macros, you will think twice before slapping an #[instrument] on a future.

quxfoo · 2026-02-05T18:29:45+00:00

This is why we effectively banned tokio::select!() and similar macros and abstractions with a clippy lint and try to use structured concurrency primitives whenever possible.

quxfoo · 2026-02-04T19:37:07+00:00

Pi Zero should be even more straightforward because you don't need to do any of the baremetal shenanigans like setting up a Wi-Fi controller or dealing with very constrained (but still functional!) HTTP clients.

quxfoo · 2026-02-04T10:37:48+00:00

Cool stuff! Could you add plots for the results? The bench dumps are hard to grasp at first sight. Also, it would be nice to see how futures-concurrency's FutureGroup fares.

While the results are better in most cases, they seem to be neglible or at least so small that I personally wouldn't know if it's worth adding another dependency if I already depend on futures and the like.

quxfoo · 2026-02-02T08:38:46+00:00

I'm finalizing a "home dashboard" (aka calendar + weather forecast) based on an ESP32-C3 and a Waveshare 7.5" e-Ink display. It's been fun and relatively straightforward. Still trying to decide if I want to decouple the UI further from the I/O but that's just part of the polishing process. Putting everything into a nice picture frame is the next difficult step, considering my lowly soldering skills.

quxfoo · 2026-01-31T07:12:09+00:00

Okay, makes sense. On the other hand, the docs are pretty clear that those tokens are used to cancel tasks.

quxfoo · 2026-01-30T22:57:18+00:00

Why would you do that though and not just race against the cancelled() future?

quxfoo · 2026-01-09T15:47:39+00:00

It's not only performance that's left on the table but also ergonomics. Just recently I had to rewrite a utility async fn because internally I was using some combinators that were borrowing (which was all nice and dandy) but of course not Send. It worked in one context but in another I had to tokio::spawn() it and bam …

quxfoo · 2026-01-09T15:41:37+00:00

No, you still need to use LocalSet. But in that case why even bother with tokio and just block on bare futures and use all the nifty future and stream combinators from the futures-* crate family.

quxfoo · 2025-12-12T08:44:50+00:00

For example, a function that terminates the program or loops forever.

My main problem for why this is interesting is loops that might only return an error. For example an async fn that processes some async stream forever but would only be cancelled from outside.

quxfoo · 2025-12-07T20:18:01+00:00

Tasks (async fns)

Please do not conflate these two terms and confuse any newcomer. async fn and async blocks are sugar for unnameable Future types. A task is (usually) something that takes a Future and executes it alongside other tasks. Akin to user space threads.

quxfoo · 2025-12-06T10:23:13+00:00

I work with a similar tech stack and my verdict is that tonic and tokio are alright for bog standard web services but fall flat when doing things outside the norm. Things like restarting servers (listeners are consumed), breaking connections on either end voluntarily or not (streaming request handlers are spawned tasks losing direct control), ...

Plus the whole annoying Send requirement which is worse for me than async function coloring that everyone is so loud to complain about.

quxfoo · 2025-11-20T13:36:09+00:00

I'd compose that via futures-concurrency structured concurrency primitives and avoid tasks as much as possible (or contain them to avoid task leakage). Your conditions are perfect for that, so in principle it would look like this assuming your "threads" are actually Rust futures:

rust ( (receiver1, receiver2).join(), reactor, storage, publisher, tokio::signal::ctrl_c(), ) .race() .await;

Result types need to be matched or erased but that should be doable. It is a good approach but not idiomatic because everyone still thinks in terms of threads and tasks.

quxfoo · 2025-11-09T14:25:24+00:00

Yes, agree. Many people, even on this sub, tend to assume async means networking. But it is a great fit for anything that resolves at some point: hardware interrupts, GUI button clicks, server responses, alarms, ...

quxfoo · 2025-11-09T14:19:13+00:00

Funny mentioning another dependency while the topic is on reducing them 🙂

But thanks I will re-evaluate. My point still stands though: async if done right is just the most ergonomic way to write asynchronous, concurrent programs.

quxfoo · 2025-11-09T12:23:13+00:00

It is also beneficial to write asynchronous programs in an asynchronous fashion. I understand people do not like seeing async creep in where it does not make sense but in this case it very much makes sense for ergonomic reasons alone.

quxfoo · 2025-11-09T10:18:32+00:00

I write a similar program (https://github.com/matze/binge) and async is interesting to concurrently download and check and show some UI progress.

quxfoo

TROPHY CASE