I think teaching barriers first would reinforce the "nothing can be reordered past this barrier" idea, instead of the barrier being a way to *upgrade* a subsequent store to release the memory preceding the barrier. Reordering kind of misses the entire point of how atomic synchronization works.

I really dislike the idea of teaching atomic orderings in terms of potential compiler/hardware reordering optimizations. That's not how the spec defines them, and that mental model can get problematic quickly. Atomic orderings prescribe visibility relationships that are actually pretty intuitive.

Very high quality code here too

Unfortunately all of my short blog post ideas evolve into books

I wonder if the bitmask approach of github.com/cloudflare/t... has any potential here?

There's a 10us state machine based solution on a local Discord leaderboard 😄.

If you go in windows of three you can try cheating once by skipping the middle item, and every iteration after that you compare the last two items in the tuple instead of the first two. Though if you do it this way you need to handle skipping the first and second items as a separate case.

I see, does your implementation essentially translate '.' to '/'?

Libraries like github.com/ibraheemdev/... are probably the best middle ground because it allows people who don't want async to still benefit from the ecosystem. It will be slower but unless someone is willing to write a professional grade synchronous HTTP 1/2/3 implementation, it's your best option.

Async might be a net negative for a lot of people, but unfortunately those people are also less likely to be investing time into maintaining quality infrastructure for synchronous code, so it's kind of of an impossible problem.

Would this "just work" if matchit supported parameters with static prefixes? e.g. `/{foo}.bar`

I have a work in progress PR that implements this github.com/ibraheemdev/... but it needs some more work for conflict handling

Do I spy matchit's new routing syntax?

I wrote a bit about the design of papaya here: ibraheem.ca/posts/design.... This release will mostly be microoptimizations that contribute to a ~15% performance improvement.

I think there's room for everyone to be more open about async not being the end all and be all of performance.

There is a little bit of nuance around async being more expensive at lower concurrency and async synchronization primitives being more complex. async-sync interop is not free, and so there is a cost on users forced to use an async library in a synchronous context.

You missed the "Windows CI is failing though"

Maybe! Though papaya's higher baseline memory usage would be an important consideration.