IIUC, this crate has similar restrictions to the std Mutex. So it depends on what you mean by "work with async code."

First, lock acquisition seems to be a blocking method. And I don't see a `try_lock` method, so the naive pattern of spinning on `try_lock` and yielding on failure won't work. It'll still work in an async function, you'll just block the executor if the lock is contested and be sad.

Second, the key and guard types are not Send, otherwise it would be possible to send a key of a lower level to a thread that has already acquired a lock of a higher level, allowing deadlocks. (Or to pass a mutex guard of a higher level to a thread that has a key of a lower level.)

Therefore, holding a lock or a key across an await point makes your Future not Send.

Technically, this is fine. Nothing about Rust async in general requires that your Futures are Send. But in practice, most of the popular async runtimes require this. So if you want to use this with Tokio, for example, then you have to design your system to not hold locks or keys across await points.

This first restriction seems like it could be improved with the addition of an `AsyncLockable` trait. But the second restriction seems to me to be fundamental to the design.

Just wanted to add to your great summary a link to tokio’s docs on which kind of mutex to use, which seem applicable to the mutex in TFA as well: https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#wh...

Also to note, regarding “future not send,” that, in tokio codebases where the general expectation is that futures will be Send, enabling the clippy lint “future_not_send” is extremely helpful in avoiding these kinds of issues and also in keeping the error localized to the offending function, rather than it being miles away somewhere it happens to be getting indirectly spawned or whatever: https://rust-lang.github.io/rust-clippy/stable/index.html?se...

Yeah, it's a pretty versatile phrase that's hard to explain. But it does often have a connotation of childishness or naivety, even when used sincerely.

It is often used an expression of thanks or appreciation, but I associate that more with an elder speaking to someone younger.

Most of the time, it is an genuine expression of true empathy, but it's not uncommon to be used as a passive aggressive expression of false empathy. It's that childish connotation that give it the extra bite when used passive aggressively.

And that plausible deniability, where the phrase is used in a genuine context often enough that sometimes you can't tell that someone is throwing shade, is very much a reflection of southern culture.

Source: Grew up in Georgia and North Carolina, with some family in Alabama.

Defining BE integer data types seems like a bad approach.

I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway.

Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.

Zombo.com is under new management.

Doesn't appear to put much strain on my Pixel 10!

Graphics and physics performance in 2026 across all kinds of hardware is wildly impressive.

Exactly. No need to engineer an allocator. You only live once!

    void* malloc(size_t size) {
        void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        return (ptr == MAP_FAILED) ? NULL : ptr;
    }

    void free(void *ptr) { /* YOLO */ }

/s

There are definitely some warning signs that OP could be a bot:

- They "no longer use Github" but their Github account was only created on March 1st.

- Their blog domain was registered on March 1st according to whois.

- They have sixteen (!!) blog posts dated March 10th.

- This is the kind of project you could vibe code: "read the ffmpeg manual and convert all of its flags into a TUI." No shade on the value of the project, just that it's a good one for LLMs.

Looks like Reddit. Ruins the clear separation between answers and comments. Terrible information density. This sucks.

I was familiar with the Gerrit workflow, but not the AGit workflow.

The original AGit blog post is no longer available, but it is archived: https://web.archive.org/web/20260114065059/https://git-repo....

From there, I found a dedicated Git subcommand for this workflow: https://github.com/alibaba/git-repo-go

I really like what I've read about AGit as a slightly improved version of the Gerrit workflow. In particular, I like that you can just use a self-defined session ID rather than relying on a commit hook to generate a Gerrit ChangeId. I would love to see Gerrit support this session token in place of ChangeIds.

I prefer the Gerrit workflow over any other git-based workflow, specially since it seems to be going the Jujutsu route in the future: https://www.gerritcodereview.com/design-docs/support-jujutsu...

- M for Model: your data model. - V for View: views of your data. - C for Controller: does stuff with your data.