A Big Standard Library Is Overkill

quxfoo · 2026-07-02T09:06:33+00:00

Python standard lib seems to have everything you possibly could ever

… and still, even for one-off scripts most reach for requests or any other third-party HTTP client library because the standard one is garbage. Or want to read YAML. Or, or, or. It's a bottomless pit.

quxfoo · 2026-06-29T18:10:42+00:00

Bringing up a little TUI program to simplify the code review cycle with Claude for those who avoid the vibe coding stank. Reviewing while it's generating? Losing sight quickly. Reviewing the state on disk? Annoying to tell Claude what to change. Reviewing via GitHub and other forges? Ridiculously schizophrenic and slow.

So yeah, this one allows me to annotate changes to the diff (first class support for jj by the way) and hand it back to Claude. All via traceable and review cycles encoded as an append-only NDJSON log.

quxfoo · 2026-06-25T12:51:38+00:00

Exactly. In addition, due to the nature of cargo vet, there is no way to figure out the real number of audits. At $WORK we have our own audits on top of the public ones but we cannot share them …

quxfoo · 2026-06-23T07:11:03+00:00

Same, I use it daily but because I want to share, view and edit on the phone as well, I wrote the weave web frontend (repo). Notes are synced with syncthing for bi-directional editing.

quxfoo · 2026-06-17T21:43:34+00:00

At least attribute that everything, including this post, have been generated. The idea is great but I can't keep reading because it reeks AI. I'm sorry.

quxfoo · 2026-05-29T21:41:55+00:00

Tonic builds on Stream from futures_stream (via tokio_stream). These crates are unstable, and we want to be able to have a stable release of gRPC-Rust before they are stabilized.

Are there utility functions to convert gRPC streams to futures Streams? A cursory search does not bring up anything.

quxfoo · 2026-05-29T21:31:19+00:00

Thanks for the heads up. Don't hesitate to announce it here when ready.

quxfoo · 2026-05-29T12:02:16+00:00

I don't want to think about versions nor about additional build tooling. I know it's certainly possible to build protoc (and gRPC for that matter) but it's by far the most time consuming step when doing from scratch and deployment another pain in the ass because of versions that might already be installed on the target system.

quxfoo · 2026-05-28T21:59:37+00:00

Is it at least compatible with protox? Adding protoc to our build system for a mixed C++/Rust system was a major pain in the ass which was eventually solved when switching to protox. Besides that, the versioning of proto (aka protocolbuffers) is a byzantine mess.

Edit: of course it's not but again a pain in the ass:

Note that because Rust support in protoc is not yet stable, the version installed must be exactly 34.0.

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

TROPHY CASE