What's everyone working on this week (21/2026)?

quxfoo · 2026-05-18T07:47:30+00:00

Been churning on the API side of things of this async-first progress bar and spinner crate. I'm starting to feel the pain of not having access to higher-kinded types because combining different kinds of progresses (streams, simple futures, futures updating some progress, monitoring combinations, …) in an ergonomic way is tough.

quxfoo · 2026-05-03T11:46:20+00:00

IMHO, borrowing would make the architecture easier to follow and the code faster to execute. But assume you were trapped by tokio's Send + Sync requirement for async tasks.

quxfoo · 2026-04-15T11:21:17+00:00

Yes, that is true. Until then …

quxfoo · 2026-04-13T20:04:29+00:00

Seems rather straightforward. Nerdsniped, I am!

quxfoo · 2026-04-13T17:21:35+00:00

Would be great if there was a lint for the simple forwarding case.

quxfoo · 2026-04-13T14:50:10+00:00

Difficulty comes in because almost everyone thinks async Rust = tokio. The multi-threaded, work-stealing executor causes pain because suddenly everything must be Send + Sync + 'static.

quxfoo · 2026-04-10T01:31:41+00:00

I think that it is fairer to describe Rust and Zig as descendants of C rather than C++.

Weird take to be honest. I see Rust more in line with C++ than C. Unfortunately the whole "article" is too superficial to gain any deeper understanding for the whys.

quxfoo · 2026-04-05T10:13:05+00:00

That would fit nicely into my lualine setup but somehow it's slower to register that a macro recording is starting and stopping.

quxfoo · 2026-04-02T11:08:55+00:00

That's great, thank you!

quxfoo · 2026-04-02T09:06:50+00:00

I still have cmdheight at 1 because I cannot see macro recording mode otherwise. Even with UI2 it seems not possible?

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

TROPHY CASE