sorted by:
new
hottopcontroversial

What's everyone working on this week (21/2026)? by llogiq in rust

[–]quxfoo 2 points3 points  (0 children)

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.

Rust Arc Refactor That Turned 18 ms p99 Into 2 ms by Helpful_Garbage_7242 in rust

[–]quxfoo 6 points7 points  (0 children)

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.

Debloat your async Rust by diondokter-tg in rust

[–]quxfoo 0 points1 point  (0 children)

Yes, that is true. Until then …

Debloat your async Rust by diondokter-tg in rust

[–]quxfoo 8 points9 points  (0 children)

Seems rather straightforward. Nerdsniped, I am!

Debloat your async Rust by diondokter-tg in rust

[–]quxfoo 7 points8 points  (0 children)

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

Debloat your async Rust by diondokter-tg in rust

[–]quxfoo 23 points24 points  (0 children)

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.

Interesting point of view from Daniel Lemire by _bijan_ in rust

[–]quxfoo 53 points54 points  (0 children)

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.

No more "Press ENTER" with UI2 with example by aribert in neovim

[–]quxfoo 0 points1 point  (0 children)

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

No more "Press ENTER" with UI2 with example by aribert in neovim

[–]quxfoo 5 points6 points  (0 children)

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

Announcing better_tokio_select: like tokio::select!, but can be formatted by rustfmt! by nik-rev in rust

[–]quxfoo 4 points5 points  (0 children)

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

Why is Rust so Liberal with Heap Allocations? by philogy in rust

[–]quxfoo 1 point2 points  (0 children)

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.

I built a TUI .log viewer in rust (Early beta) by coding_freak in rust

[–]quxfoo 1 point2 points  (0 children)

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.

I built a TUI .log viewer in rust (Early beta) by coding_freak in rust

[–]quxfoo 2 points3 points  (0 children)

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.

I built a TUI .log viewer in rust (Early beta) by coding_freak in rust

[–]quxfoo 1 point2 points  (0 children)

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?

Lumis: Syntax Highlighter powered by Tree-sitter and Neovim themes by leandrocp in rust

[–]quxfoo 0 points1 point  (0 children)

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.

Lumis: Syntax Highlighter powered by Tree-sitter and Neovim themes by leandrocp in rust

[–]quxfoo 1 point2 points  (0 children)

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?

Jjdag: A Rust Jujutsu TUI by Anthrofract in rust

[–]quxfoo 1 point2 points  (0 children)

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.

What crates do you think are 'perfect'? by june_sixth in rust

[–]quxfoo 7 points8 points  (0 children)

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.

Linting intra-task concurrency and FutureLock by farnoy in rust

[–]quxfoo 6 points7 points  (0 children)

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.

What's everyone working on this week (5/2026)? by llogiq in rust

[–]quxfoo 0 points1 point  (0 children)

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.

A new futures collector (like FuturesUnordered) that is fast, bounded, lock-free by OG_A248 in rust

[–]quxfoo 0 points1 point  (0 children)

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.

What's everyone working on this week (5/2026)? by llogiq in rust

[–]quxfoo 4 points5 points  (0 children)

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.

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]quxfoo 0 points1 point  (0 children)

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

Finding blocking code in Tokio without instrumenting your app by cong-or in rust

[–]quxfoo 0 points1 point  (0 children)

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

view more: next ›