2026-03-25 10:10:00
A while back I was talking to a friend of mine about looking at the Google Street View images of the neighbourhood I grew up in.
"And look at all the empty space next to the church! You can see the next hill over. This house looks like war rubble but I'm pretty sure it was just abandoned."
"Yeah," said he, "I feel the same way looking over photos of my old neighbourhood myself. It looks like a warzone."
"Thank God I escaped there, man. Can you imagine if I was still there?"
Can you imagine?
A while back I ran a campaign of Delta Green, and the whole thing made me introspective.
Of the last players in the campaign, one was Finnish, one was American, and one was Brazilian like me. Despite that, in the absence of an interesting, deeper setting to study, I went and learned more about what the United States of America is like. I wanted to know what the streets of New Hampshire are arranged like, what the typical job of someone in North Dakota is, how much the crisis of opioids would have affected a small town in Kentucky. I realised I knew a lot about that already through media exposure, half-remembered factoids, and just interacting a lot with them over the past two years. None of it was as detailed as the knowledge someone who had actually been there could relate, but I'd say I got as close as I could have gone.
By the end of it, when I was taking notes on the effects of the atrocities committed by Purdue Pharma in West Virginia and Kentucky, it suddenly hit me: I had never ran a game that was as Brazilian as this game was American.
It is a common refrain among the youth to condemn, or gingerly admit, that we are "a colonised people - if not by the Portuguese, then by the Americans". Many are those who rage against American music, proudly extolling the virtues of Brazilian MPB and Bossa Nova; who reject those "foreign movies" in favour of our telenovelas and our own national cinema; who ask what need is there for Hemingway or Fitzgerald when we have Machado de Assis and Monteiro Lobato.
I have never felt at home with those people, because at the end of the day, those slogans feel more like out-loud confessions; a shameful admission of the guilt you feel for partaking in this "American colonisation" while not refusing it entirely.
After all, we can sing the praises of Chico Buarque and Tom Jobim as much as we want, it does not change that their main inspirations were foreign musicians: Caetano Veloso had the cash to "exile himself" in the late 60's and early 70's to sing about the Londonian Portobello Road, after all. Watch one hundred and one Brazilian movies, and you will notice the entire Cinema Novo movement was made in dialogue and response to the French New Wave and Italian Neo-realism. In the pages of our books from the 19th century (pretty much all of which were made in and about cities on the coast, particularly Rio de Janeiro), the reader will be showered with longing mentions and comparisons towards Paris and Lisbon.
Tarsila do Amaral, shortly after the Modern Art Week of 22 which inaugurated Modernism in Brasil, crafted the Abaporu as an open question: what does beauty mean in the tropics? What is left if you scrape off Portugal, France, and the United States from our canvases? The canvas was a challenge: here, I remove the face, the more emblematic aspect of many European screens, and I emphasize the body, the size, the hugeness.
I don't think anyone since then has meaningfully answered Tarsila do Amaral, only reiterated her question. And every single time they reiterated it, the patterns were updated, because Yankee and European culture kept seeping in here. How could it not?
Thus, the proud youth who loudly protests their Brasilidade always sound like they protest too much; that they feel the need to loudly proclaim they are not that, because to stop and ponder what is left if the foreigner isn't looking - to be left to wonder who you are in the dark - is a proposition none is willing to face.
Having realised this, I was left to wonder: when did all of this begin? We can go back as far as you want.
Shortly before independence, in the 1790's, the Minas Gerais Conspiracy attempted to launch a revolution in the shape of the American one - the conspirators even tried to get Thomas Jefferson to support them, but couldn't. Over the course of the 19th century we were at our most outward-facing, since the Imperial government did not want to associate themselves with the fractured, unstable, and "indigenous" Latin America, instead painting this country like an European monarchy that happened to be localised in the tropics - using the fact that the Portuguese royal family had fled Napoleon to Brasil in 1808 as evidence of that. Thus the gap between Brasilidade and Latinidad widened.
I thought to look for our first works of fantasy. Out there, the British, the French, and the Yankees had had very high literacy rates for a long time, thus being able to revolutionise popular and genre literature, which, through a convoluted process, slowly created the conditions that allowed for fantasy literature to be made.
We did not have that. Our literacy rates have always been quite low and it took a century of efforts to reduce it; magazines were generally not as big here up until the 90's (since the dictatorship of the 60's to the 80's did not enjoy "subversive material" such as... Superman) and most literature was published through feuilleton, sold along with the newspaper for the "doctors" - Law graduates, bureaucrats, the wealthy baronial class and the ascending middle class.
As far as I am aware, the first out and out fantasy novel that became famous here was Reinações de Narizinho (Adventures of Lucia Little Nose), published in 1931, which became part of the beloved series Sítio do Pica-Pau Amarelo (The Yellow Woodpecker Farm), which was later adapted as a children's TV show in 1952, and in every decade thereafter, embedding itself in our popular consciousness as deeply as Alice in Wonderland or Peter Pan have in the United Kingdom.
One of the first fantastical elements that our heroine, Lucia Little Nose - an aristocratic child from the inner country in her grandma's slave-owning-coded farm - finds is the cowboy Tom Mix, the star of the silent-era American Western. He is portrayed as fantastical an element as a prince of fishes who lives in the nearby pond or a talking corncob, through the incredible power of being an American.
The hard truth I had to confront after this is that there is no "back then", when we had no interaction with the USA and Europe and art was genuine; no prior time to the current one, when the songs on the radio weren't covers from American songs with the words switched up, and the TV shows weren't a Brazilian version of "The Voice" or "The Apprentice".
Or rather, we did, but it did not survive. There were likely made-up stories of wondrous and woeful things found in the hinterlands, of mysterious hauntings and monsters, told by a parent in the dim light through a language that was not quite Portuguese. But much like Goya's Pinturas Negras, these creative endeavours were painted in oil on the darkened walls of a walled off room and left to rot. Whatever they were, they were either not written down, or were commercialised and turned into something else - something which could be repackaged and sold in New York City.
There is much bitterness in that proposition, and I don't think the average Anglo quite understands this DuBoisian double consciousness, because unlike in the society of that hallowed thinker, the North American is not looking back. We see ourselves through the disinterested eyes of those who do not look in our direction, and this can boil over into what some call the mongrel complex - a collective inferiority complex, nowadays used as derision for those who would espouse the views that all which is Brazilian is inferior, and which can be most often felt by constant calls of "Come to Brasil!" online; "Please notice us! Please validate us!"
Yet the eyes remain not being ours. Nothing can change the fact that, when we turn on the television to watch Everybody Hates Chris, his rowhouse downtown apartment in Bedstuy in the 80's appears luxurious; that the snow he is complaining about is wondrous to those from this snowless land. No American will quite know what it feels like to grow up listening and singing songs whose words you don't quite understand; celebrating Christmas with faux snow decorations in the middle of tropical summer; having someone with brown skin call themselves "black" rather than "pardo"; watch your little cousin romanticise owning Air Jordans before those were even sold at shoe stores.
But there is something comforting about that - there is to me, at least. I find some solace in the idea that our birthright is that discomfort, that constant search for identity and that constant adaptation of the foreign into something that can be recognisably "ours". It's what rappers did in the 80's and 90's, openly discussing James Brown in their lyrics; it's what MPB did in the 60's and 70's; what Bossa Nova did in the 40's and 50's, and so on.
In many ways, to be "Brazilian" is to be in tension with what it means to be Brazilian - an identity you know is real to some extent, but which was so haphazardly cobbled from different cultures that one can barely put into words what it means. An identity of opposition, characterised more by what we are not than by what we are; an identity sewed together by an aristocracy that put to death all those who fought for autonomy and freedom. As the song goes: "And from war to peace, from peace to war / Every time the folk from this land can sing / They sing of pain."
To a hungry nation like Brasil, every piece of culture is a mouth chewing forever; a stray dog gnawing on any bone it can clench its jaws around; a toucan happily drinking from an open coconut. None of this is original, this was the conclusion the Anthropophagic Movement reached - a movement inspired by Tarsila do Amaral's Abaporu. I, too, appear not to have an answer to her question, because the question "What does beauty mean in the tropics?" might have an answer in the Caribbean or the Andes, but in Brasil, the colossus which stands together yet apart from Latin America? That question might as well be the defining characteristic of Brasil, of what it means to be Brazilian. It has as much of an answer as "Was Napoléon Bonaparte good?" has for France - how much time do you have?
I did not have a lot of money growing up. A lot of Brazilians who can speak English will follow up a phrase like that discussing how their parents, who have university degrees and Italian or German last names, made a "modest living" through some mean or another which allowed them to "take a trip or two to Orlando or Paris", to get haircuts with the same price of a brand new Playstation 3 videogame, among other scabrosities.
I am not that fortunate. My mom is a telemarketer with no university degree, her mom was a stay-at-home wife and charwoman after her husband - who worked construction - passed away from a brain tumour - and her father, my great grandfather, was a Portuguese man from the Ilha da Madeira who owned no land, worked the ground as much as he could, and when he couldn't, worked as a night watchman. My father lucked into his first job without a degree and managed never to get fired. and thus makes a pretty good living, all things considered; my grandfather is a self-taught almost-illiterate electrician, and my grandmother a seamstress. I come from a long line of proletarians.
The place I grew up in were the outskirts of my city - Campinas, which in the times of slavery was used as a threat, the place where rebellious slaves would be sent to. Dialectically, it was also the place where Luís Gama made his career, the first black lawyer in the country. I attended school right next to where the street ended and there was just undeveloped tall grass. To the side of where I lived, just beyond a tall wall, was a pasture. The community was quite literally at the end of the road. This is what it looked like when I was about 11:
This is what the church I attended looked like:
I spent a lot of time at my aunt's house, whose neighbourhood was also the last one before undeveloped land that looks about like that.
Odds are that when you think of Brasil, you don't think of a place like this. You might think of beautiful beaches, dramatically mountainous geography, half naked brown bodies tanned by the sun playing "soccer" or dancing samba. If you are Brazilian, you also don't think of these places. Even if you think of poverty, you think of the dramatic northeastern arid lands, mud soil cracked by the sun; or in the massively sprawling favelas, the concrete panopticon.
The big difference is that those places have a culture of their own. The favelas are the birthplace of the now-internationally famous funk music, if you go on the internet you can find a reason for them being there, an explanation that one day, long ago, presidents decided to demolish downtown tenements, and all those poor and desperate people had to go somewhere, even if it had to be up the mountain.
And the northeast is the ground-zero for Brazilian culture; some of our greatest works of literature describe the poverty there (such as Vidas Secas and Grandes Sertões: Veredas), some of our greatest movies describe the dramatic violence that took place there (such as Black God, White Devil). It is a land of much pain and much culture - my grandpa came from there.
The place I was raised in isn't like that. There is no drama there, there is no history. Look up any place there online, you will find nothing. Try to find any artist from this land, and the name of Hilda Hilst will politely turn up - a poet known for her isolation - or the composer Carlos Gomes, who left this land behind for the northeast and Rio de Janeiro as soon as he could.
All that is there is cattle, dirt roads, and a piece of concrete too prosaic to feel like a half-remembered dream, or someone's memory of a town, or any florid descriptor you might want to attach to it. No one has any deep ties to this place, most people's grandparents, like mine, migrated here during the rural exodus and built this city in the 50's to be a place of work. No one has any stories of "what was once here", no folklore was brought, no one's parents tell them mysterious tales of what might lay just beyond the pasture, because we know there is nothing there. The TV shows all come from America, the songs my parents heard in their youth were whatever was on the radio - to my mom, Hall & Oates sound like "music from my generation". The culture I was weaned on in the 2000's featured next to nothing produced in Brasil, by Brazilian sensibilities, with the intent of stimulating a Brazilian culture - and all that did felt terribly coastal. No literature I read in school told me of what laid in the fields next to my house, they talked of the distant metropolis of Rio de Janeiro; no telenovela I watched impatiently while waiting for my time on the TV to come on took place in a tiny apartment on the edge of town, where shirtless boys rode bicycles and confabulated about having seen a strangely shaped shadow through a window once.
When I and many like me were children, we felt on our sun-tanned skins the reality that underpins those faux nationalistic calls for a "more Brazilian culture" - and many of us are glad we escaped the cultural wasteland that are the parts of Brasil that the eyes of the foreigner never saw. Therefore I feel no guilt in picking and choosing from what comes my way, in eating from every morsel of culture and digesting it into what can be called "mine". Let English become overgrown. Let the jaguar who lost its forest claim the plantation for its own. English is mine, my forest, growing in my homeland. It is not my mother tongue, but I refuse to die hungry.
2026-03-25 06:32:00
Some weeks back there was a popular post on the Discovery page recommending another blog (I don’t want to call anybody in particular out, because this is just an example of a society-wide trend!). This was an authentic human saying “I love this blog, the writing is beautiful and it really speaks to me”. Wanting to feel inspired myself, I checked out this other blog and every single post was AI-generated. Specifically, it was very obviously ChatGPT. It was generated last year so before so many people were wise to the tells, and did have the em dashes edited out, but otherwise every paragraph was packed do the absolute gills with doing things "quietly" and introducing thoughts with "And honestly?" and if you're familiar with LLM writing you get the idea.
If you aren't — I've noticed people can get a little defensive and uncomfortable when a so-called "LLM tell" is a word or phrase they use in their own writing, but I really don't think this is necessary! Despite people's fears that they'll be mistaken for AI I've yet to meet anybody who's natural writing sounds anything like AI. You might have one tell but not all of them at once.
Anyway.
One one level it shouldn't matter if one person found a robot thought-provoking. Or when people rely to a ChapGPT slop post on Reddit with "oh my gosh this was so well written" or a ChapGPT quip with "hilarious!!!!!" We can find meaning wherever we want! But whenever I encounter somebody who likes this stuff I feel this growing sense of dread and it's even worse when they clearly don't know it's AI they're responding to.
I guess it's scary to think maybe I'm getting tricked somewhere, by more subtle LLM product, and I have no idea.
And those of us who want to write, it's distressing if some people think a robot does it better.
But I also just get mad. This is what people want?! This is crap! Most of this kind of writing doesn't build to anything, doesn't say anything. It doesn't even try to make its paragraph different lengths.
Ultimately I just get worried that I'm going to spend the rest of my life running from my least favorite author of all time. I checked out a physical book from the literal library that had ChatGPT-generated text in it! Who will stop this bastard?!
--
This post was last edited 1 day, 2 hours ago.
You can reply by email.
2026-03-25 04:00:00
Cash is universally accepted within the boundaries of your country, predictable and anonymous. Transactions require no intermediary, nor a processing fee. It is tangible and has no cybersecurity vulnerabilities.
We might only realize what we had once it is gone. If you can, use it more often.
2026-03-25 02:53:37
This website is for me. I’ll probably do a future post about what that means. For now though, I want to share how I avoid seeing any the site’s metics.
What gets measured, gets done.
I host this site on Bear Blog, which measures a few thing by default:
Here’s how I turn them off.
On your Dashboard, go to Settings
and then Advanced settings
. Uncheck Collect analytics
and hit Save
.
Add this to your theme’s CSS:
#upvote-form .upvote-button .upvote-count {
display: none;
}
Click Save
. Boom! Gone!
You can hide any blog from your Discover feed. I hide my own. It’s not like I need to discover it.
If you really want to make your presence known, get in touch.
5-a-side was cancelled, so I'm having a chill evening at home.
2026-03-25 00:59:35
Just got back from the gym. Phew!
Not quite the same as twenty years ago. I’m over 50, and trust me, it’s hard to ignore. I can’t lift the same weights, have the same intensity, or get the same body as those half my age.
If that were my motivation, I would have given up a long time ago.
But it’s not about that, and it’s not really about staying strong and in shape either. That’s a nice bonus, but it’s not what drives me the most.
My main motivation is the discipline. It feels good to stick to the routine. It leaves a nice feeling of accomplishment, even if I’m the weakest guy in the gym.
I feel the same way about blogging. It’s a nice feeling when a post gets noticed, and it’s wonderful getting readers’ feedback, but that’s not what motivates me.
If that had been my goal, I would have quit a long time ago. Some posts get attention, most posts don’t, often the ones I personally like the most. That’s fine.
My main motivation for blogging is the discipline. It feels good to write a blog post, no matter what happens after I hit publish.
It’s a personal accomplishment, and that reward is what matters the most.
2026-03-24 23:43:00
I run a finance web app built with Quart, the async-native counterpart to Flask. I chose Python for a practical reason: finance is my main domain, and most of the people around me understand Python. Very few of them work comfortably at the systems level, so in many cases I still need to stay grounded in Python.
At the same time, I have been building tools that let me push more of the heavy finance data work down into C. One of those projects is a Pandas-compatible replacement aimed at keeping more of the pipeline at the C level, so I can avoid climbing back up the stack unless I actually need Python. But that's a story for a different article.
In this post I will provide a map layout of how I built a Quart accelerator: Zigguart, where it enables a Python web framework to have massive throughput capacity.
I think the easiest way to misunderstand Zigguart is to treat it as one more attempt to make a Python web stack a little faster. That description catches the surface of the project, but it misses the real point.
Zigguart is interesting because it changes where the work happens. Instead of assuming that every request has to become a normal Quart request, it asks a more useful question: which requests actually need Quart (and Python) at all?
That question matters because ordinary performance tuning has a pretty low ceiling. You can make JSON a bit faster, reduce copies, improve pooling, and clean up middleware ordering, all of which helps. Even after all that, the basic shape of the request is still the same. The server accepts the connection, Python owns the request lifecycle, the framework builds its abstractions, and the application runs. A better version of the usual path is still the usual path.
Zigguart is trying to break that assumption. In a standard Quart deployment, the picture is straightforward:
Internet -> Granian -> Quart
With Zigguart Mode B, it becomes:
Internet -> Zigguart -> Quart
That is the single change at the architectural level: Zigguart moves in front of Quart and becomes the server that sees the request first. Inside Zigguart, the flow is more detailed. A request can be rejected early, served from the Zig cache, or passed through the embedded Python bridge into Quart. The important point here is simpler than the internal mechanics. Quart stops being the thing that has to own every request from the beginning.
The most accurate short description: Zigguart moves Quart off the hot path without giving up Quart. That is the real ambition: it keeps Quart where Quart is useful and tries to erase Quart where Quart has become repetitive overhead, while not forcing a rewrite to another framework.
This is what makes the project more interesting than generic "Python, but faster" marketing. A lot of performance work in web applications still lives inside the assumption that every request must become an application request. In practice, many high-traffic routes are stable enough that rebuilding the whole framework path on every hit is simply wasteful. If a response can be replayed safely, the fastest place to do that is in front of the framework, not inside it.
That is the real design move. Zigguart puts a native layer in the only place where order-of-magnitude wins are even available: before the Python framework wakes up. Once you do that, repeated requests stop being opportunities for micro-optimization and start becoming candidates for elimination.
The big headline numbers only make sense if you interpret them correctly. When Zigguart produces a large warm-route speedup, that does not mean template rendering became magically cheap or that database access suddenly improved by two orders of magnitude. It means the route is no longer taking the normal application path on repeated hits.
That is an important difference. On a real cache hit, Zigguart can skip the parts of the stack that usually dominate Python web serving:
At that point the unit of work changes. The system is no longer "running the web app again." It is replaying a cached response from native memory. The server looks up the bytes, assigns the headers and body, and writes them to the socket. That is why the warm-path numbers can become so dramatic without being dishonest.
The project is not claiming that Python itself has become absurdly fast. It is showing that repeated traffic can often avoid Python entirely.
This is also why Zigguart feels more like an accelerator than a typical server. A normal high-performance ASGI server is still excellent at serving Python requests. Zigguart is strongest when it can prevent a request from needing to become a Python request at all ~ avoiding any processes at Python level if possible.
If you pay attention, I keep on repeating the point on avoiding any processes / operation. This is a simple design decision where people often forget: don't process if it's not needed, don't try to be "sophisticated" by adding unnecessary complexity to your design. Return to the first principles of design.
The first major strength is obvious once you look at the control flow. Zigguart gives the earliest decision to Zig. That matters more than any isolated micro-optimization, because the earlier you decide, the more work you can avoid. If Zig were still sitting behind Quart, the ceiling would stay modest. Moving the native layer in front of Quart is what gives the design its headroom.
The second strength is the cache itself. cache.zig is not just a storage mechanism. It is part of the execution model. The cache is in-process, Zig-owned, and consulted before the Python fallback path. A hot hit is served from the native server path, not from a Python callback that happens to fetch something cached. That distinction is easy to miss, and it is the reason the project cannot be reduced to "the app has caching now."
The third strength is that Zigguart is not transport-only. It has app-facing acceleration concepts because the goal is not merely to parse HTTP quickly. It tries to understand when an application route can be short-circuited safely. That is why route classification, @simple_json, @cached_route, and the promotion rules matter. They are attempts to define where application semantics can be preserved while the framework cost is avoided.
The fourth strength is narrower but still important: the project is very clearly Quart-first. That focus gives the work a real identity. Zigguart is not trying to be the universal answer for every Python async framework on day one. It is trying to make an existing Quart app fast without forcing a rewrite. That is a practical goal, and it is one reason the project feels more grounded than many performance experiments.
The fifth strength is easier to overlook because it does not show up in a flashy benchmark graph. Zigguart has spent real effort on correctness. Trusted proxy handling, cache-safety restrictions, request bounds, overload shedding, and shutdown behavior are all part of the story. Once Zig sits in front of the app, the server becomes part of the trust boundary. At that point, sloppiness turns a fast-path demo into a liability. Zigguart has mostly taken the harder route and treated the front layer like real infrastructure.
One reason the project holds together conceptually is that the Mode B pieces have clear jobs. server.zig owns process startup, worker lifecycle, shutdown, and the main runtime. httpz gives the project a Zig-native HTTP/1.1 substrate without burying it in a full framework. cache.zig provides the warm-path engine. python_embed.zig keeps CPython and the fallback event loop alive inside the process. asgi_bridge.zig turns a miss into a real ASGI call and extracts the response back into the native side.
That last file is where the tradeoff becomes visible. It is the compatibility layer, and it is also the place where cold traffic still pays a lot. The bridge has to build request state, cross into Python, wait for the framework to run, and then bring the result back out. That is why the project is strongest when it can keep traffic away from this path.
I think the most elegant part of the design lives in python_embed.zig.
The code literally inverts the usual relationship between Python and the server. Python stops being the server and becomes a service living inside the server. That is more than an implementation detail. It is the architectural statement that makes the rest of Zigguart coherent.
The benchmark numbers only become meaningful once they are separated into warm and cold behavior. Warm traffic is where Zigguart proves the architecture. Repeated routes that can be cached and replayed are where the project becomes convincing. That is why the review numbers can show strong gains on routes like summary, market_page, commodity_specific_oil, and, on some paths, much larger wins still.
The clearest data point is the latest warm Quart_FA comparison:
Latest results — zigguart-httpz vs zigguart-granian (warm traffic)
benchmark/results/20260321-105626 · wrk 4 threads · 64 connections · 10 s · Linux x86-64
These are real Quart_FA production routes: HTML pages, DB-backed stock summaries, commodity pages, and earnings tables. Those are not JSON response where usually is used by most web framework benchmarks. The only JSON response from the bench was the health endpoint where it consists of 10 lines of nested JSON. The rest are full HTML pages.
The key point is that both sides of this benchmark already use the same Zigguart cache:
zigguart-httpz: Zigguart cache + http.zig server pathzigguart-granian: Zigguart cache + Granian server pathThis is not "cached Zigguart" versus "uncached Granian", both above combo received the same zig-cache benefit. Warm means the Zig cache is already populated, Python has already run once for that URL, and subsequent requests are served from cached responses. The remaining difference comes from the server path itself. Even after both sides get the same Zig-cache benefit, the standalone Zig server still serves those cached responses orders of magnitudes faster than the Granian-backed path.
While those results are real, they also need to be described honestly: a 100x result does not mean Quart became 100x faster. It means the repeated request no longer travels through Quart in the ordinary way. The server has moved the work to a different place, and on the hot path that change dominates everything else.
The spread in the numbers is also informative. Smaller warm-route multipliers usually correspond to heavier bodies or routes that still have meaningful transport and replay cost even after caching. Very large multipliers show up when the old stack keeps paying Python costs for a route that Zigguart has reduced to a native cache hit. The numbers vary because the route shapes vary. That is exactly what you would expect from this design.
This is also the right place to mention the part that can sound like magic if it is not explained properly. The "Zig-cache magic" is not some mysterious extra optimization layer. It is simply the consequence of where the cache lives and who owns it. cache.zig sits in front of the fallback path, inside the server, and stores replayable responses as native server data.
On a warm hit, Zigguart is not "using Python more efficiently." It is skipping Python and replaying the response from Zig. That is the mechanism behind the benchmark table above.
Cold traffic tells a different story. A cold miss is expensive as it still has to pay for the bridge, for Python scheduling, for response extraction, and for whatever work the application itself does on that miss. On Quart_FA, that application-side cost is not small. Startup warmers, CSV loading, SQL fan-out, pandas transformations, and template rendering all pile on top of the server’s own fallback work. That is why the project looks much less dominant on cold misses than on warm hits. It is not a contradiction. It is the natural limit of the current architecture.
Zigguart is closest in spirit to Granian. That is the most useful comparison, because Granian also moves serving work out of the traditional Python stack and tries to make the transport layer efficient enough that the framework stops dominating every request. Uvicorn and Hypercorn are still useful reference points, but they occupy a different role. They are broader, more mature, general-purpose ASGI servers.
The distinction matters because Zigguart is not trying to win by breadth. It is trying to win by changing the hot path.
Uvicorn and Hypercorn want to be reliable servers for Python apps in general. Granian wants to be a very fast server for Python apps. Zigguart is trying to become a server where the hot path often stops being a Python application request at all.
That gives it a narrower identity, but also a more distinctive one. The fairest way to describe Zigguart at this stage is probably this: it is an early-stage, Quart-first, Granian-like server with an additional application-acceleration layer. That is a better description than calling it a drop-in general-purpose replacement for every mature ASGI server, because it tells you what the project is actually optimizing for.
The Quart focus is more than branding. It shapes the whole project. In a lot of performance conversations, the implicit answer is that if you care enough, you should move to a different framework. Sometimes that is the right answer. In other cases, the app already exists, the framework fits the product, and the real problem sits lower in the stack.
Zigguart comes from that second situation. It assumes the Quart app is worth keeping and that the serving model is the part that should change. That is why the project feels more practical than a full framework rewrite. It also explains why it has app-facing concepts instead of staying purely transport-shaped. The project is not chasing abstract server speed in a vacuum. It is trying to keep Quart where Quart is valuable and remove Quart where it has become repetitive machinery.
The obvious objection is that this all sounds like a more complicated way of describing a cache, and that Redis already exists. Redis is excellent at shared storage, cross-worker reuse, persistence across restarts, and centralized invalidation. A Quart app can absolutely benefit from Redis.
What Redis does not do is change who serves the request. A Redis-backed Quart app still moves through the normal Python server path before the cached value becomes useful. Zigguart solves a different problem. Its cache sits directly in the serving path, in native memory, in front of Python. A hot hit can be served before the framework is involved at all.
That is why Redis is better understood as a possible complement, not a replacement. If Zigguart ever wanted a second-level shared cache, Redis would be a sensible L2. Replacing cache.zig with Redis entirely would weaken the most valuable part of the project, because the hot path would stop being a pure in-process native response path.
If you ask "why not just use Redis?", you're asking the wrong question. The useful question is whether it is valuable to move repeated traffic off the Python request path completely. Zigguart is built around the idea that the answer is yes ~ avoiding any processes in the Python level.
The weak spot is cold traffic, and that needs to be stated plainly. The architecture shines when it can avoid the fallback path. It is much less impressive when it has to take the fallback path and the application itself is heavy on a miss.
That does not mean the architecture is wrong. It means the project is still living with the cost of compatibility. The fallback bridge is real work. The app behind it is also real work. In Quart_FA, that means cold summary requests are carrying startup contention, data loading, SQL work, dataframe processing, and template rendering on top of the bridge cost.
So the honest reading is simple. Warm traffic already proves the core idea. Cold traffic shows where the unfinished engineering remains. That is not a bad place for the project to be, but it does make the next priorities clear.
Even with the cold-path weakness, I still think the architecture is worth pursuing because it is pointed at the right problem. The biggest wins in serving usually come from moving responsibility to the right place in the stack. Zigguart has done that. By putting the native layer in front of the framework, it has given itself a chance at very large wins that would simply never appear inside the ordinary Python request path.
It also avoids the ridiculousness of "rewrite the app in X language" as the only way forward. The project keeps Quart for the complex path and strips Quart out of the repetitive path. That is a much more attractive migration story than telling a working application to change its framework for the sake of the server.
At this stage I would not describe Zigguart as the final form of a general purpose Python async server. I would describe it as a serious Quart-first server and accelerator that has already proved one very important point: moving the serving decision in front of the Python framework changes the economics of a real web app in a meaningful way.
Zigguart core components are written in Zig, a low level systems program language aiming to be "a better C". If you follow my posts then you'd know I love writing C programs, so much that I modified my C version to use safe_c.h and then built cgrep and cforge with it.
Plenty of projects use a faster language around Python, but I feel Zig is special as it has 1:1 structure to C and it's easier to get to a lower level than C. What makes Zigguart unique is that it gives Quart a different serving model while still letting the application remain a Quart application.
I think this is the real architectural contribution: it changes how repeated traffic is served, it explains the warm-path benchmark numbers cleanly, and it points to a alternative method where the framework is used where it adds value instead of where habit placed it. By habit I mean: the default old pattern where every request automatically goes through the Python framework.
The project is not finished. The cold path still needs real work. The maturity gap with broader servers is still there. Even so, the central idea has already proved itself. Zigguart shows that a Quart app does not have to live forever inside the full Python request path, and that is a strong enough result to make the project worth continuing.
If you enjoyed this post, click the little up arrow chevron on the bottom left of the page to help it rank in Bear's Discovery feed and if you got any questions or anything, please use the comments section.