DEV Community: Mahmoud 🦀

No, Seriously. Neural Networks Cannot Produce Genuine Intelligence.

Mahmoud 🦀 — Sun, 11 Oct 2026 05:36:17 +0000

Hey everyone 👋,

I want to start by saying something that I know is going to make a certain type of person deeply uncomfortable, and I want to say it before the disclaimers, before the caveats, before the politely worded softening that usually surrounds this kind of statement. Here it is: I am sorry, but no. Neural networks are not capable of real, genuine, fully autonomous intelligence, and I need you to sit with that sentence for a moment before you start typing your rebuttal. I said genuine intelligence. Not artificial intelligence, not useful intelligence, not impressive intelligence. Genuine. That word is doing enormous work in that sentence, and I chose it with the same care I choose every other word I write. In my previous post Genuine Intelligence will never in trillion years emerge from neural networks, I laid out the architectural argument from first principles. In All You Have Access To Is Knowledge and Tools; Never Intelligence!, I showed that the entire intelligence narrative built around current AI systems is a category error dressed up in venture capital language. In Knowledge and Intelligence ARE Mutually Exclusive, I pushed that argument further. In this post I am going to go one more step, because something has shifted in the public conversation recently that requires a direct and unapologetic response, and I am the person who is apparently going to give it.

The shift I am talking about is the following. A few months ago, the AI discourse was dominated by claims about language model reasoning. Before that it was claims about emergent capabilities. Before that it was claims about few-shot generalization. Each cycle, a new capability gets announced with increasing breathlessness, a new wave of LinkedIn posts declares that the singularity is here, and then 6 months later the researchers publish the papers showing what was actually happening under the hood, and it was pattern matching again. This cycle has been running for years. What is different now is that the current claims have escalated to the level of full autonomy. The claim is no longer that models can reason; the claim is that models are fully autonomous agents that can conduct scientific research, develop software, run business operations, and govern themselves without meaningful human oversight. And I need to explain, carefully and without being polite about it, why that claim is not just premature but structurally impossible given what neural networks actually are. Not impossible because the technology needs more time. Impossible because the mechanism is wrong. The same way a bicycle is structurally impossible to fly regardless of how technically refined it becomes, because the mechanism of a bicycle is not the mechanism of flight.

I also want to say something before we go further about the phrase genuine autonomy, because I am using it in a specific and demanding sense and I want to be honest about what that sense is. Genuine autonomy means the capacity to set one's own goals, to evaluate the quality of one's own reasoning, to identify when one's own knowledge is insufficient, to decide what new knowledge to seek and how to seek it, to operate across novel domains that were not anticipated during design, and to do all of this without requiring a human at the end of the decision chain to validate, redirect, or supervise the process. That is the bar. It is a high bar. It is also the bar that every serious definition of autonomous agency sets, and it is the bar that current AI systems, regardless of wrapper, do not reach and cannot reach with the current architecture. I am going to spend the rest of this post explaining why with some humor because otherwise I would lose my mind, and with the same directness that I used in every post before this one.

Wait, What Do You Mean By Genuine Intelligence vs Genuine Artificial Intelligence?

I know the first objection coming, and I want to cut it off before it finishes forming. You are about to tell me that I am splitting linguistic hairs. You are about to say that the distinction between genuine intelligence and genuine artificial intelligence is just a semantic game, a rhetorical move that lets me redefine my terms whenever the AI does something impressive. I want to tell you no, and I want to tell you why. The distinction is not about semantics. It is about mechanism, and mechanism is the thing that determines what a system can and cannot do regardless of how impressive it looks from the outside. Genuine artificial intelligence, in the sense the term has been used since the 1950s, means systems that can mimic intelligent behavior. Artificial is the key word. The intelligence is a mimicry, an artifact, something made to resemble intelligence rather than something that is intelligence. We have had genuine artificial intelligence since GPT-1. The models predict plausible, contextually appropriate text. That is a form of artificial intelligence. It is impressive, it is useful, and nobody should pretend otherwise.

Genuine intelligence, without the artificial qualifier, means something categorically different. It means the capacity to understand the world as it is rather than as it was described in the training data. It means the capacity to form new concepts from first principles rather than recombining concepts that were absorbed during training. It means the capacity to be wrong in a productive way, to notice the wrongness, to investigate it, to generate a hypothesis about why, to test that hypothesis against reality, and to update. It means the capacity to function in genuinely novel domains with no prior training context for that domain. A 12 year-old human child has genuine intelligence in this sense. The child can walk into an unfamiliar situation, form a model of what is happening, make predictions, get corrected by reality, and update their model. They do not need a training set for every new situation. They need the general capacity for model formation and causal reasoning, which develops through embodied experience in the physical world and which no transformer architecture produces through text prediction. The difference between these two kinds of intelligence is not a matter of degree. It is a matter of kind, and collapsing that distinction is how we end up with billion-dollar systems that confidently hallucinate medical diagnoses.

I also want to address the specific version of the objection that says intelligence is a spectrum and the models are somewhere on it. This objection sounds measured and scientifically responsible, but it contains a hidden assumption that I reject, which is that the mechanisms of human intelligence and the mechanisms of neural network prediction are the same mechanism operating at different intensities. They are not. They are different mechanisms. A thermometer measures temperature in a way that is mechanistically completely different from how your body feels temperature. A photograph of a landscape is mechanistically completely different from a painting of the same landscape. Both the thermometer and your skin produce a response that covaries with temperature, but one is an engineered measurement and the other is a felt experience rooted in biology, and they are not on the same spectrum. Similarly, a language model produces outputs that covary with intelligent human outputs because it was trained to do so, but the process producing those outputs is mechanistically different from the process producing human intelligence, and being on a similar output spectrum does not make them the same kind of thing (1). The history of AI is full of systems that produced outputs indistinguishable from intelligent behavior on narrow tasks and then failed completely when the task changed even slightly. That failure is the signature of a mechanism mismatch, not a capability gap that will close with scale.

The practical dimension of this distinction matters enormously and is not being discussed honestly in the public conversation. When companies deploy systems as autonomous agents and claim those systems are genuinely intelligent, they are making an implicit promise about the range of conditions under which those systems will perform reliably. Genuine intelligence implies robustness across novel conditions. Artificial intelligence implies reliable performance within the training distribution. Those promises are completely different in scope, and the gap between them is where people get hurt. A system that is genuinely autonomous can be trusted to handle situations that were not anticipated during design. A system that mimics autonomy can only be trusted to handle situations that are close to what it was trained on, which is a critically different trust relationship, and conflating them is how we end up with autonomous vehicles that fail in light rain, autonomous medical advisory systems that fail with unusual patient presentations, and autonomous coding agents that confidently introduce security vulnerabilities that no human reviewer would miss. The linguistic distinction between genuine and artificial intelligence is not a game. It is the most practically important distinction in the entire field.

But OpenAI Just Solved Mathematics, So Checkmate?

Deep breath. Deep breath. Okay. Let me say this as kindly as I can manage, which is not very kindly. I already wrote about this general category of result in multiple previous posts and predicted it would happen, which means the result was not surprising to me, and I want to explain exactly why it should not be surprising to anyone who has been paying attention. A model trained on the entirety of human mathematical knowledge, which includes not just the correct theorems but the failed proofs, the partially solved problems, the heuristics, the analogies, the researcher notes, the textbook exercises, the competition problems, and the entire corpus of mathematical reasoning as expressed by humans over several centuries, that model generating solutions to problems that were previously unsolved is expected. I did not say it is unimpressive. I said it is expected. There is a difference, and the difference matters for what we conclude from it.

The Navier-Stokes problem is a genuinely hard mathematical problem. Let nobody suggest I am dismissing its difficulty or its importance. But the way the model approaches a hard mathematical problem is not the way a mathematician approaches a hard mathematical problem. A mathematician builds a conceptual model of the problem space, identifies the structural feature that makes the problem hard, looks for analogies in other areas of mathematics that share that structural feature, formulates a hypothesis about what kind of argument strategy might work, explores that strategy, gets stuck, backtracks, reformulates, and eventually either succeeds or concludes that the approach was wrong. That process is generative intelligence operating on a causal model of the mathematical structure. What the model does is something statistically similar to pattern completion over a learned representation of mathematical text, and the fact that this can sometimes produce correct proofs for previously unsolved problems is remarkable but it is not evidence of genuine mathematical intelligence any more than a sufficiently detailed weather simulation is evidence that the simulation understands meteorology (2). The simulation produces correct predictions. It does not understand. The model produces correct proofs. It does not understand. These are not the same thing.

I also want to say something about the specific framing of "OpenAI has solved mathematics" that appears in every breathless tech news headline when one of these results drops. Mathematics is not a set of problems to be solved. Mathematics is a living, generative discipline that creates new problems faster than it solves old ones, because in mathematics the solution to a problem almost always reveals new structure that opens 10 harder problems. The Mossad agents who normally help me with my architectural decisions apparently also help me with my epistemology, and they would point out that the interesting question is not whether the model can solve the existing unsolved problems but whether the model can formulate new problems that reveal new mathematical structure. Chollet argued in his landmark paper on measuring intelligence that skill acquired through training is fundamentally different from the fluid intelligence required to form entirely new problems, and that metrics which reward skill without measuring generalization ability give a systematically misleading picture of what a system can do (3). Ramanujan did not solve existing problems. He discovered entire new areas of mathematical structure that nobody had imagined. A language model trained on Ramanujan's work can reproduce patterns from his work. It cannot be Ramanujan.

The pollution dimension of this situation also deserves explicit attention, because it is already happening and its consequences are already visible. As AI companies race to demonstrate mathematical or scientific capability, they are flooding academic preprint servers and research journals with AI-generated content at a rate that exceeds the human capacity for review and evaluation. The result is not an acceleration of scientific knowledge. The result is an acceleration of scientific content, which is a different and far more dangerous thing. Scientific content without the verification, the debate, the failed replication attempts, the collegial argument that slowly separates the genuine advance from the plausible-sounding error, that content is not science. It is noise that looks like science, and it degrades the ability of the research community to identify and build on genuine advances. I wrote in LLMs destroyed the Internet. LMMs will make it alive about how automated content generation destroys the epistemic value of the information environment. The same dynamic is now operating in the scientific literature, and the long-term cost is the trustworthiness of science itself. Nobody is excited. Nobody is shocked. And nobody should be, because this was predictable.

I want to also directly address the human dimension of this, because I think it gets lost in the excitement over capability demonstrations. We human beings value effort not as a quirk of our psychology but because effort is the mechanism by which understanding is produced. The struggle to solve a hard problem, the years of failed attempts, the moments of insight that feel like gifts because they follow months of fruitless work, those are not inefficiencies to be optimized away. They are the process by which a human mind builds a deep causal model of a problem domain. When a system produces a solution without that struggle, the solution may be correct but it is also orphaned. It has no parent understanding. Nobody who holds that solution knows why it works in a deep enough sense to know where to go next. This is the reason that human mathematicians are, almost universally, not excited about AI-generated proofs. The proof is not the point. The understanding that the proof reveals is the point. A proof you did not struggle to find is a solution to a crossword puzzle completed by someone else. You have the answer. You do not have the understanding. And in mathematics, as in everything that actually matters, the understanding is the whole game.

But GPT-N Omega Pro Max++ Vibe-Coded This Entire Game Fully Autonomously?

Here we go. Let me compose myself. Okay. I am composed. This argument comes up constantly now, and it follows the same template every time. An AI model, usually labeled with some impressive name involving a high number or a Greek letter, produces a functional artifact, usually a game, a website, or a piece of software, without explicit human instruction at the code level, and the result is presented as evidence of autonomous creativity and genuine intelligence. I need to take this apart, carefully and without losing my temper, because the argument is seductive and the counterargument requires more than a sentence to deliver properly. So let us be thorough about it.

The first thing to understand about a model generating a functional game autonomously is what the word generating means in this context. The model does not create the game the way a human game developer creates a game. A human game developer starts with a vision, an aesthetic, a set of mechanics, a world, a set of rules that interact in interesting ways, and then implements all of that through a sequence of design and engineering decisions that each encode an aspect of the original vision. The interesting part is not the code. The interesting part is the creative vision that the code expresses. A language model generating a game produces code that is a collage of patterns from similar games in its training data, recombined in ways that happen to produce a functional result. The result may run correctly. It does not express a creative vision, because the model has no communicative intent, no aesthetic intention, no sense of what would be interesting or meaningful to a player. Bender et al. argued precisely this in their foundational critique of large language models: that these systems are stochastic parrots producing form without meaning, statistical mirrors of human text that carry none of the communicative intent that makes human language meaningful (4). It has learned what game code looks like, and it produces something that fits that learned distribution.

The second thing to understand is that nobody wants to play the game. And this is not a small point. This is the entire point. A game's value to a player is not its technical correctness. A game's value is its soul, its lore, its narrative, its sense of humor, its respect for the player's time and intelligence, and above all its feeling of having been made by someone who cared about the experience of playing it. These are properties that I can detect immediately when I pick up a game, and so can you, even if you cannot articulate them precisely. When someone tells you that an LLM generated this entire game, something in you deflates, and that deflation is not irrational. It is a recognition that the thing is a hollow artifact. It runs, but nobody meant it. And meaning is not an optional luxury feature of creative work. Meaning is the entire reason creative work has value to the people who experience it. A game without meaning is just a physics engine with textures. You would get more out of asking the LLM to live-stream a playthrough of the game for you on the fly, which the LLM can do, and which would be more interesting to watch than playing a game that nobody genuinely imagined.

The third thing to understand is the structural incompleteness of what gets described as fully autonomous generation. What the model actually did in every documented case of this type, when you look at the methodology rather than the marketing, is generate a frontend scaffold for a simple game loop, using patterns from similar open-source games in its training data. The complete experience of a game in the real world involves enormously more infrastructure than a scaffold. It involves backend services, matchmaking systems, chat infrastructure, anti-cheat systems, persistent player state, telemetry, analytics, abuse reporting, content moderation, accessibility features, localization, monetization systems, third-party service integrations, compliance with platform policies, and decades of iterative refinement based on player feedback. None of that exists in the autonomously generated output. What exists is a proof of concept that demonstrates the model can produce code that resembles the code of games it was trained on. Calling that full autonomous game development is like calling a photograph of a house the house. The photograph is an artifact that references the structure. The model output is an artifact that references the functionality. Neither of them are the thing itself.

I also want to say something about the direction this argument is going, because I see it more and more: the claim that because the model can produce the surface form of creative work, the model is producing creative work, that because it can generate code that compiles, it is doing software engineering, that because it can write a sentence that is grammatically complex, it is engaging in literary expression. This is the philosopher's zombie problem applied to AI, and I want to name it clearly. A philosophical zombie, in thought experiment form, is an entity that behaves exactly like a conscious being in every observable respect but has no inner experience of that behavior. The behavior is there. The inner life is not. Current AI systems are philosophical zombies of intelligence. They produce the behavioral outputs associated with intelligence. The inner process producing those outputs is pattern completion over a learned statistical distribution, not reasoning, not understanding, not intention, not creativity. And a zombie playing chess is not a chess player. It is a zombie that makes moves. The distinction matters for what you trust the zombie to do next.

What LLMs Are Actually Doing, and Why It Is Just The Tip of The Iceberg

I want to be fair here, because I have been consistently fair in every post I have written, even when the thing I am being fair about is something that is actively used to argue against positions I hold. LLMs are powerful. They are more powerful than most people thought possible five years ago. They are useful, they are economically valuable, and the scale of what they can do within their training distribution is genuinely impressive. I wrote all of that in LLMs are Usefull. LMMs will Break Reality, and I stand by every word of it. But power within a training distribution is not the same as autonomy, and the gap between what LLMs can do and what production systems require is not a gap that can be bridged by wrapping the model in a better API.

Think of a language model as a very sophisticated for-loop with memory. At each step, the loop looks at the current context, applies a search over the learned representation space, samples from the resulting distribution using some randomness to prevent deterministic collapse, and appends the result to the context before running the next iteration. That is a real and powerful computation. It is also a computation that is entirely reactive. It does not initiate. It does not plan beyond the immediate token horizon. It does not build a model of what it is trying to accomplish and monitor the gap between that model and the current state. It responds to input with statistically appropriate output. This is enormously useful for code completion, for document summarization, for information synthesis, for translation. It is not autonomous operation. Shanahan, in his careful philosophical treatment of what it means to talk about large language models honestly, argues that the anthropomorphism enabled by LLMs' fluency in human language makes us systematically vulnerable to describing them in terms that do not match their actual mechanism, and that repeated stepping back to ask what the system actually does will almost always reveal a reactive prediction engine rather than a reasoning actor (5).

The production software systems that people actually run in the real world are not merely frontend scaffolds. They are layered stacks of interacting subsystems, each with its own failure modes, its own performance characteristics, its own operational requirements, and its own behavioral contracts with the other subsystems. A game on a real production platform has a game server cluster, a matchmaking service, a leaderboard service, a player identity and authentication service, a database cluster with replicas and backup procedures, a CDN for asset delivery, a monitoring and alerting stack, a deployment pipeline, a rollback procedure, a DDoS mitigation layer, and usually somewhere between three and five third-party service integrations that each have their own documentation, API limits, and failure behaviors. The model that generated the game frontend has no knowledge of any of this beyond the surface patterns it absorbed from documentation text in its training data. Building production systems is an exercise in understanding the mechanisms of failure across a complex interacting set of subsystems, and understanding failure mechanisms requires causal models that no language model has (6).

The voice chat room in an online game is not a text generation problem. The latency constraints, the packet loss handling, the codec selection, the server-side mixing, the abuse detection in audio streams, the GDPR compliance for voice data, the integration with the client application, the regional routing for low latency, none of these are problems that get solved by generating plausible-sounding text about how voice chat would look. They are engineering problems that require deep understanding of network protocols, audio signal processing, distributed systems, regulatory frameworks, and the specific constraints of the game's platform and user base. The autonomously generated game has none of that. It has a textbox. And a textbox is not a voice chat room, no matter how many parameters the model that generated it has. This is not a criticism of the model. It is a description of what the model is and is not, and what production software is and is not, and why those two things are not the same.

I want to connect this to something I said in All You Have Access To Is Knowledge and Tools; Never Intelligence! about the frame problem. The frame problem, in practical engineering terms, is the problem of knowing which things change when you take an action and which things do not. When you deploy a new version of a service, what changes is the behavior of that service. What must not change, if you want your system to continue working, is the behavioral contracts between that service and everything it interacts with. Managing those contracts, reasoning about what is downstream of what, identifying which changes are safe and which are breaking, that is the daily work of a software engineer operating in a production system. It requires a causal model of the system. It requires the capacity to simulate what will happen when a change propagates through a layered stack of interacting services. A language model can produce code that looks like service code. It cannot reason causally about what will happen when that code runs in the production system, because it does not have a causal model of the production system. It has text about systems that look similar. That is the tip of the iceberg. The iceberg is everything that the text does not capture, and in production engineering, the iceberg is where ninety percent of the work lives.

The Autonomy Illusion: How Wrappers Become Worldviews

One of the most sophisticated-sounding arguments for AI autonomy goes like this: yes, the model itself is just pattern completion, but wrap it in the right scaffolding, give it memory, give it tools, give it the ability to call itself recursively, and you get something that is functionally autonomous even if the underlying mechanism is not. I hear this argument a lot from people who are technically sophisticated, and I want to engage with it honestly because it deserves engagement rather than dismissal. The argument is not crazy. There are systems architectures where simple computational units combine into systems with properties that no individual unit has. Neurons are simple threshold devices. Brains compute extraordinarily complex things. So why can't a simple language model plus scaffolding produce genuine autonomy?

The answer is that the brain analogy fails at the level of mechanism, and mechanism is the thing that matters. Neurons combined into brains produce intelligence because the combination instantiates specific computational structures, specifically causal inference over hierarchical generative models, that are capable of producing genuine reasoning, genuine model formation, and genuine updating in response to prediction error (7). The computation is grounded in physical reality through sensorimotor experience that provides labeled prediction errors across millions of daily interactions. The structural organization of the brain, the cortical hierarchy, the basal ganglia, the hippocampal memory systems, the thalamic gating, is specifically adapted over millions of years of evolution to produce the kind of learning and inference that counts as intelligence. Wrapping a language model in scaffolding and memory does not replicate any of this. It adds a context management layer on top of a reactive prediction system. The scaffolding does not change what happens inside the prediction step, and the inside is where the intelligence would have to live.

Memory does not solve the problem. Memory gives the model access to more text context. But having access to more text does not produce causal reasoning from that text. It produces pattern completion over more text. A model with a million-token context window is not more intelligent than a model with a four-thousand-token context window. It has more information available for its pattern completion. That is a real and useful improvement. It is not a mechanism for producing genuine reasoning, because the mechanism producing the output at each step is still pattern completion, regardless of how much context is available to that step (8). A person who reads more books is not smarter than a person who reads fewer books in any direct proportional sense. A person who reads more books has more raw material for their intelligence to work with. The intelligence doing the working is not in the books. It is in the cognitive architecture that was shaped by evolution and development long before the first book was opened.

Tool use does not solve the problem either, and I made this argument at length in All You Have Access To Is Knowledge and Tools; Never Intelligence!. A language model that can call a calculator, a search engine, and a code interpreter is a language model plus three lookup operations. The intelligence required to know which tool to use in which situation, to interpret what the tool returns, to integrate the tool output with the rest of the reasoning context, that intelligence has to live somewhere. And in the agentic architecture, the place it is supposed to live is the language model. But the language model's behavior in that role is still pattern completion over training data about how agents use tools, not genuine reasoning about which tool is appropriate for the current problem. The result is that the tool-augmented agent fails in characteristic pattern-matching ways on novel tool usage situations, which is exactly what the research shows (9). You can add recursion too. The model can call itself repeatedly, reflecting on its own output, generating a chain of self-assessments. But each step in that chain is still a pattern completion step, and a chain of pattern completion steps is not reasoning any more than a chain of coin flips is a decision. The appearance of self-reflection does not instantiate self-reflection.

Genuine autonomy requires something that none of these scaffolding additions provide, which is an internal model of the task that allows the system to distinguish between situations where the current approach is working and situations where the current approach is failing, and to adaptively switch strategies based on that distinction. That is meta-cognitive control, the ability to monitor the quality of one's own cognitive processes and to intervene when quality is insufficient. Research on human metacognition has established that this capacity develops through years of embodied feedback, through the experience of trying, failing, noticing the failure, trying differently, and building a model of one's own cognitive strengths and weaknesses in specific domains. Language models have a statistical approximation of metacognitive language, they can produce text that sounds like self-assessment. They do not have the underlying process, the monitored internal model that the self-assessment text is supposed to describe. The words are there. The referent is not. And an autonomous agent without genuine metacognitive control is not an autonomous agent. It is a system that will continue confidently in the wrong direction for as long as the statistical distribution of its training data supports doing so.

The Research Nobody Wants to Read But Everybody Should

I want to spend time in this section on the empirical evidence, because I believe strongly that the argument I am making is not just philosophically sound but empirically grounded in a body of research that is not making it into the popular conversation with the prominence it deserves. The popular conversation about AI capability is substantially driven by benchmark performance announcements, demo videos, and press releases. The empirical research literature on what AI systems cannot do is substantially less visible. That asymmetry is not neutral. It shapes what people believe about the current state and trajectory of AI, and beliefs shape decisions, and decisions about AI deployment have real consequences for real people.

The research on AI agent reliability is the most directly relevant to the autonomy question, and the results are unambiguous. Kambhampati et al. demonstrated from first principles that auto-regressive LLMs cannot, by themselves, perform sound planning or self-verification, because the next-token prediction mechanism does not implement the look-ahead and backtracking required for global goal alignment (9). This theoretical argument is validated empirically in large-scale agent benchmarks: the WebArena evaluation placed state-of-the-art GPT-4-based agents on realistic long-horizon web tasks and measured a task success rate of only 14.41 percent against a human success rate of 78.24 percent, representing failure rates exceeding eighty-five percent on tasks that a capable human completes routinely (10). The failure modes are consistent and predictable: agents take locally plausible actions that compound into globally incorrect outcomes, and when they encounter situations that do not match their training distribution, they either fail to recognize the mismatch or continue confidently toward the wrong outcome. These are not random failures. They are the systematic signature of a system that lacks a global model of the task and is therefore unable to detect when the local action is inconsistent with the global goal. A genuinely autonomous system would detect this inconsistency and recover. A pattern-matching system cannot, because detecting the inconsistency requires comparing the current state against a model of the intended state, and that kind of model-based comparison is not what pattern completion produces.

The research on distribution shift, which I discussed in Genuine Intelligence will never in trillion years emerge from neural networks, has continued to accumulate in the same direction. Study after study finds that AI systems perform reliably within their training distribution and unreliably outside it, and the performance degradation is dramatic rather than gradual. Taori et al. systematically evaluated 204 ImageNet classification models across 213 different test conditions and found that robustness gains from synthetic perturbation training rarely transferred to natural distribution shifts, and that virtually no existing technique fully closes the performance gap between in-distribution and naturally shifted test sets (11). This is the canonical signature of a system that has learned to exploit statistical regularities in the training data rather than learning the underlying rule that generates the data, and it appears consistently across architectures, scales, and domains. It does not go away with more scale. It changes in its specific manifestations as the model becomes more capable within its distribution, but the structural incompatibility between pattern matching and genuine generalization remains. More impressive pattern matching is still pattern matching, and pattern matching does not become autonomy at any scale.

The research on AI in high-stakes professional domains is perhaps the most concrete evidence of the autonomy gap, because these are exactly the domains where genuine autonomy would be most valuable and where its absence is most costly. Obermeyer et al. conducted a landmark analysis of a commercial health-management algorithm and found that it systematically underestimated the health needs of Black patients because it used healthcare cost as a proxy for health need, encoding the structural reality that Black patients had less access to care into a learned bias that treated them as healthier than equally sick White patients (12). The algorithm was not doing medicine. It was doing pattern matching over a dataset where the patterns encoded centuries of unequal access. A genuinely autonomous medical reasoner, one operating from a causal model of pathophysiology, would not confuse spending patterns with health status. A pattern-matching system cannot distinguish between them, because in its training data, they covary, and covariation is all it can learn. The bias shows up not as a subtle statistical artefact but as a systematic, measurable failure that affects real patients in real clinical settings, and it is invisible to the system producing it because the system has no model of the mechanism generating the pattern.

The research on AI legal reasoning has found similar patterns. Dahl et al. conducted the first systematic profiling of legal hallucinations in large language models and found that legal hallucinations were alarmingly prevalent, occurring between 58 percent of the time with GPT-4 and 88 percent of the time with Llama 2 when models were asked specific, verifiable questions about federal court cases (13). The model that passes the bar examination has learned the statistical distribution of bar examination questions, which is a specific and relatively well-defined distribution that diligent pattern matching can handle. But when the same model is asked to retrieve or reason about actual legal specifics, specific case names, specific holdings, specific statutes in specific jurisdictions applied to specific novel fact patterns, it confabulates with high confidence, because the specific combination has no reliable match in the training distribution and the model has no actual model of legal structure to reason from. Dahl et al. also found that LLMs often cannot correct a user's incorrect legal assumptions, and frequently do not know when they are producing a hallucination, which is the overconfidence signature in its most dangerous possible form. This is happening in systems already deployed in real legal contexts, serving real clients.

Genuine Intelligence Requires Genuine Grounding, and That Grounding Cannot Be Simulated in Tokens

There is a philosophical concept called grounding and it explains a great deal about why text-trained models cannot achieve genuine autonomy. Grounding refers to the connection between a symbol and the thing in the world that the symbol refers to. When I use the word hot, my use of that word is grounded in my experience of touching hot surfaces, of feeling the burns, the warmth, the danger signal, the automatic withdrawal reflex. That experience is what gives the word hot a meaning that goes beyond its statistical relationship with other words. A language model's use of the word hot is statistically associated with other words like fire, pain, temperature, summer, and coffee, and that statistical association allows it to produce contextually appropriate text involving the word hot. But the word is not grounded in any felt experience of heat. It is an ungrounded symbol, and ungrounded symbols cannot support genuine reasoning about the referents of those symbols in the way that grounded symbols can (14).

The grounding problem is not merely philosophical. It has direct practical consequences that show up in specific failure modes. A model with ungrounded symbols cannot reason about physical interactions in novel situations because its knowledge of physical interactions is stored as statistical associations between words that describe physical interactions, not as a model of the physics itself. Ask the model to predict what will happen when you drop a cube of ice into a glass of warm water, and it will produce the correct answer because that scenario is well-represented in its training data. Ask it to predict what will happen when you drop a specific non-standard material with specific non-standard thermodynamic properties into a specific non-standard fluid under non-standard pressure, and it will confabulate, because the specific combination has no statistical precursor in the training data and the model has no actual physical simulation to fall back on. A genuinely intelligent system would use its physical model, its understanding of thermodynamics, to compute the answer for any combination of materials and conditions. The model uses its training data, which means it only knows what it has been told about specific scenarios. And there are infinitely many specific scenarios that nobody has written text about.

The solution to the grounding problem is not more text. More text does not ground symbols in physical reality. More text gives you more ungrounded symbols with richer statistical relationships to each other. A model trained on every physics textbook ever written has abundant statistical associations between physics words. It does not have a single simulation of a physical process grounded in the actual dynamics of the physical world. This is why I have argued across multiple posts for the importance of mathematical models and physics simulations as the alternative architecture. Mathematical Equations are Multimodal by default describes why equations are more honest representations of physical reality than text, because equations encode the mechanism rather than a description of the mechanism, and mechanisms are what ground the predictions in reality. A model built around equation discovery and physical simulation has symbols that are grounded in the dynamics of physical reality. A language model has symbols grounded only in other text. The first kind of grounding supports genuine reasoning about novel physical situations. The second kind supports sophisticated text generation about familiar textual patterns. Those are not the same capability.

Embodied cognition research has established over the past three decades that human intelligence is not separable from the body that hosts it and the physical world that the body interacts with (16). When you understand what it means to grasp something, that understanding is rooted in the sensorimotor experience of grasping, the feel of fingers closing, the resistance of the object, the proprioceptive sense of hand position and grip strength. Your understanding of the abstract concept grasping a concept is a metaphorical extension of that embodied experience, and research shows that even processing abstract language activates sensorimotor neural systems involved in the corresponding physical actions. Intelligence is not a disembodied computation over abstract symbols. It is a computation deeply intertwined with a physical body that experiences the world and updates its models on the basis of that experience. Language models, by design, have no body, no sensorimotor experience, no felt consequences for wrong predictions, and no physical world to update against. They have text. Text is a description of embodied experience. A description of embodied experience is not the same as embodied experience, and intelligence built on descriptions cannot do what intelligence built on experience can do.

I want to close this section by saying something about what genuine grounding would require that I think is underappreciated. Genuine grounding requires not just sensory data but the feedback loop between predictions and their consequences. It requires a system that has made predictions about the physical world and had those predictions either confirmed or disconfirmed by events in that physical world, and that has updated its internal model on the basis of that feedback. This is the reinforcement learning setup in its genuine sense, not the RLHF approximation that is used to fine-tune language models, but actual reinforcement learning where the signal comes from the physical world. Reinforcement learning in that genuine sense can produce grounded representations of the world, as demonstrated by robotics systems and simulation-trained physical agents. But those systems are not language models. They are a different architecture solving a fundamentally different problem. And the intelligence produced by genuine reinforcement learning against physical reality does not transfer from the language model paradigm regardless of how large the language model becomes.

We Do Not Even Know What We Do Not Know, and That Is the Real Problem

One of the most dangerous properties of current AI systems in deployment is the combination of high capability within the training distribution and high confidence everywhere. The system does not degrade gracefully as it approaches the edge of its competence. It falls off a cliff while still sounding absolutely certain. This is the property that I find most troubling about the current deployment environment, more troubling than any specific failure mode, because it makes the failures unpredictable and therefore unmanageable. If a system degraded gracefully and signaled increasing uncertainty as it approached the edge of its competence, you could deploy it with appropriate monitoring and respond to the signals before the failures had consequences. But a system that fails while sounding confident fails silently, from the user's perspective, until the failure has already had consequences.

Calibrated uncertainty, the property of knowing what you do not know, is a defining feature of genuine intelligence and a property that neural networks systematically lack in their base form. Guo et al. demonstrated in a foundational study of neural network calibration that modern deep neural networks are poorly calibrated compared to their predecessors, that they are systematically overconfident, and that this overconfidence grows with model depth, width, and the use of batch normalization, meaning that the architectural choices that make neural networks more accurate also make them more overconfident in their wrong answers (15). A model that has seen many confident-sounding statements in its training data will produce confident-sounding statements in contexts that resemble its training data, regardless of whether that confidence is warranted in the specific case. This is not a calibration bug that can be patched. It is a structural consequence of the training objective, which rewards producing confident predictions on training examples and has no direct mechanism to penalize overconfidence in the specific situations where the model's knowledge is weakest.

The absence of genuine metacognitive monitoring is the root cause. A genuinely intelligent system would monitor the quality of its own reasoning, flag when it was operating in unfamiliar territory, and scale its expressed confidence to match its actual epistemic state. This kind of metacognitive monitoring is what humans call knowing what you know and knowing what you don't know, and while humans are imperfect at it, the basic capacity exists and can be trained and improved. In neural networks, the absence is architectural. The model produces its outputs through a single forward pass, without any separate process that monitors the quality of the reasoning or evaluates the confidence of the output against the strength of the evidence. Techniques like sampling-based uncertainty estimation give a proxy for disagreement between model samples, but that proxy is not the same as genuine metacognitive monitoring, and it does not prevent the confident production of confident-sounding wrong answers. The model does not know what it does not know because it does not have a model of what it knows. It has weights. Weights do not know things. They encode statistical associations, and statistical associations do not have an epistemic status that the model can introspect and evaluate.

For a genuinely autonomous system, calibrated uncertainty is not optional. It is the mechanism by which an autonomous agent decides when to act on its own judgment and when to seek additional information, defer to a human, or flag a decision as requiring review. Without this mechanism, an autonomous agent will make high-stakes decisions in low-competence situations with the same apparent confidence as low-stakes decisions in high-competence situations, and the consequences of that cannot be managed at the deployment layer. You cannot fix a systematic overconfidence problem with monitoring alone, because the monitoring has to use the same system's outputs to assess the same system's confidence, and the system is wrong about its own confidence. This is the autonomy gap in its most concrete operational form. An autonomous vehicle that does not know where its competence ends is not safer than a human driver who does know where their competence ends. It is dramatically less safe. And scaling the model does not change the fundamental absence of the metacognitive architecture that would make it possible for the model to know what it does not know.

What Would Genuine Autonomous Intelligence Actually Require?

I want to be honest and constructive here because I have been making a primarily negative argument for most of this post and I genuinely believe in the possibility of building genuinely autonomous intelligent systems. I do not believe current neural networks can get us there. I believe the alternative direction exists and is the right one, and I want to describe it clearly. If you have read my previous posts, you have seen pieces of this argument scattered across multiple places. Here I want to assemble those pieces into a description of what the right architecture would need to look like.

First, it would need causal modeling rather than statistical association. The difference is not subtle. A causal model of a domain represents the mechanisms that generate the observations, not just the statistical relationships between observations. A causal model of a medical domain would represent the biological mechanisms by which diseases produce symptoms, not the statistical correlation between symptoms and diagnoses in a training dataset. Causal models support genuine generalization because they generalize at the level of mechanism, which is domain-invariant, rather than at the level of surface patterns, which are training-distribution-specific. Judea Pearl's work on causal inference and the do-calculus provides the mathematical foundation for this, and the field of causal machine learning, while early stage, is producing real results (17). This is the right direction. It is also harder, slower, and less impressive in demos than scaling language models, which is why it is underfunded and understaffed relative to its importance.

Second, it would need symbolic reasoning over learned representations, not just learned representations by themselves. Symbolic reasoning is what provides the truth-preserving inference rules that allow a genuine reasoner to derive new knowledge from known knowledge in ways that are reliable rather than statistically likely. The neurosymbolic research program, which I described in Genuine Intelligence will never in trillion years emerge from neural networks, is the most promising approach here. It attempts to combine the representation learning strengths of neural networks with the structured inference strengths of symbolic systems. The engineering challenges are real but the theoretical case is solid. A system that can learn good representations from data and reason over those representations using principled inference rules would have systematic compositionality, would support genuine logical reasoning, and would avoid the surface-pattern dependence that characterizes pure neural approaches.

Third, it would need physical grounding through interaction with the real world rather than text descriptions of the real world. This means some form of sensorimotor experience, either through robotics, through physics simulation with real physical fidelity, or through other forms of direct interaction with physical processes that produce genuine prediction errors when the system's model is wrong. The lmm project I have been building is an attempt to implement a piece of this, with symbolic regression for discovering physical equations from data rather than ingesting descriptions of physical equations from text. An LMM architecture that learns physical laws from measurements of physical processes has symbols grounded in physical reality in a way that a language model trained on text descriptions of physical laws does not. The grounding is genuine because the equations have been validated against real physical data, not because someone wrote down that the equations are valid.

Fourth, it would need genuine metacognitive architecture, a separate process that monitors the quality of the primary reasoning process and has the authority to intervene, redirect, or flag uncertainty when warranted. This is not the same as adding a reflection step to the language model output. A reflection step is still a language model output, a pattern completion over descriptions of what good reflection looks like. A genuine metacognitive architecture is a separate computational process with a different objective from the primary reasoning process, specifically the objective of evaluating whether the primary reasoning is working and the objective of identifying when it is not. The computational structure for this exists in various proposals in the cognitive science and AI literature, and while no current system implements it in a satisfying way, it is a tractable engineering problem rather than an impossible one. The impossibility is not in building genuine metacognitive architecture. The impossibility is in producing genuine metacognition from a single-objective next-token prediction training process. You need to build the metacognitive capacity explicitly. It does not emerge from scale.

Where Do We Go From Here, And What Honest Progress Looks Like

I want to close this post the way I have closed every post before it, which is by saying something honest rather than something comfortable. The honest state of affairs is this: neural networks are extraordinarily powerful tools that operate within their training distributions with impressive and genuinely useful capability. They are not genuinely autonomous agents, they are not genuinely intelligent, and they will not become either of these things through further scaling of the same architecture. The gap between what they are and what genuine autonomous intelligence requires is architectural, not quantitative, and architectural gaps require different architectures, not more of the same architecture. This is not pessimism about AI. This is clarity about what the current tools are and a call for honesty about the gap between them and what we are claiming to build.

The progress that would actually matter, the progress toward systems that can reason causally, that have grounded representations, that can generalize systematically, that know what they do not know, is happening in smaller research communities with less funding and less visibility than the communities building larger and larger language models. Causal machine learning, neurosymbolic AI, physics-informed learning, symbolic regression, embodied AI, all of these research directions are producing results that are more relevant to genuine autonomous intelligence than anything coming out of the scaling race, and they are producing those results with a fraction of the compute and a fraction of the investment. The academic incentive structure, the funding structure, and the media attention structure are all pointing in the wrong direction. The right direction is harder, slower, and does not produce demos that trend on social media. But it is the direction that leads somewhere real.

For those of you who build things, which is most of the people I know and most of the people who read this blog, the honest implication of this argument is that you should use current AI tools for what they are good at, which is significant, and build your systems with appropriate understanding of where those tools fail. Do not build systems that depend on AI judgment in situations that fall outside the training distribution unless you have robust monitoring and human oversight for exactly those situations. Do not tell your users that your system is autonomous when it is a language model in a scheduling for-loop. Do not cite benchmark performance as evidence of real-world capability in novel domains. These are not technical requirements. They are honesty requirements. And honesty about what our tools can and cannot do is the minimum ethical obligation of anyone who builds and deploys systems that affect other people's lives.

The future I want to build toward, and the one I am working on in my small way with the lmm project, is a future where artificial systems earn the word autonomous through demonstrated behavior in situations that were not anticipated during design. Not through impressive demo performance on curated benchmarks. Not through confident-sounding answers to questions that happen to be in-distribution. Through genuine generalization to genuine novelty, through honest uncertainty when facing unfamiliar territory, through the capacity to form new understanding rather than retrieve old patterns. That future is technically achievable. It requires different architecture, different training objectives, different evaluation criteria, and different honesty from everyone involved in building and deploying these systems. It also requires that we stop congratulating ourselves for the current tools as though they are already there, because they are not, and pretending otherwise is how we make the journey longer, not shorter.

Till next time 👋!

References

1. Searle, J. R., Minds, Brains, and Programs, Behavioral and Brain Sciences, 1980

2. Marcus, G. & Davis, E., Rebooting AI: Building Artificial Intelligence We Can Trust, Pantheon Books, 2019

3. Chollet, F., On the Measure of Intelligence, arXiv:1911.01547

4. Bender, E. M., Gebru, T., McMillan-Major, A. & Shmitchell, S., On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?, ACM FAccT 2021

5. Shanahan, M., Talking About Large Language Models, arXiv:2212.03551

6. Bommasani, R. et al., On the Opportunities and Risks of Foundation Models, arXiv:2108.07258

7. Friston, K., The free-energy principle: a unified brain theory?, Nature Reviews Neuroscience, 2010

8. Dziri, N. et al., Faith and Fate: Limits of Transformers on Compositionality, arXiv:2305.18654

9. Kambhampati, S. et al., LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks, arXiv:2402.01817

10. Zhou, S. et al., WebArena: A Realistic Web Environment for Building Autonomous Agents, arXiv:2307.13854

11. Taori, R. et al., Measuring Robustness to Natural Distribution Shifts in Image Classification, arXiv:2007.00644

12. Obermeyer, Z., Powers, B., Vogeli, C. & Mullainathan, S., Dissecting racial bias in an algorithm used to manage the health of populations, Science, Vol. 366, 2019

13. Dahl, M. et al., Large Legal Fictions: Profiling Legal Hallucinations in Large Language Models, arXiv:2401.01301

14. Harnad, S., The Symbol Grounding Problem, Physica D: Nonlinear Phenomena, 1990

15. Guo, C. et al., On Calibration of Modern Neural Networks, ICML 2017

16. Lakoff, G. & Johnson, M., Philosophy in the Flesh: The Embodied Mind and Its Challenge to Western Thought, Basic Books, 1999

17. Pearl, J., Causality: Models, Reasoning, and Inference, Cambridge University Press, 2009

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:36 +0000

Nǐ hǎo 👋!

You've seen the textbox. You've typed the number. You've waited three seconds for the SMS that never came, checked your spam folder, clicked "Resend", typed the number again, and finally admitted to yourself that 2FA is simultaneously the most important and most annoying invention of the modern web.

Today, we make it marginally less annoying, at least on the Rust side. We're shipping OTP RS.

What Even Is OTP RS?

OTP RS is a composable, accessible, animated One-Time Password input component for Yew, Dioxus, and Leptos. It implements the full verifier flow: slot-by-slot input, keyboard navigation, active/filled/invalid/disabled states, animated caret blink, digit-entry pop animation, and RFC 4226 (HOTP) + RFC 6238 (TOTP) validation, all in Rust, all in WASM, all without touching a single line of JavaScript.

If you've ever tried to build a 6-box OTP input from scratch, you know the drill. It starts with "just six inputs". Two hours later you're debugging focus management, backspace propagation, keyboard event edge cases, browser autofill hijacking your state, and the invisible iOS number pad refusing to appear. That's the origin story of OTP RS.

Component Architecture

OTP RS follows the same composable anatomy as every other component in the Open SASS Kit. You compose what you need:

Otp: Root container. Owns the internal value state, focus coordination, and the RFC validation callbacks.
Group: A visual cluster of slots (e.g., three digits, then a separator, then three more).
Slot: Individual slot. Renders a visible character display on top of an invisible overlay <input>.
Separator: The little dash in between groups.

use otprs::yew::{Otp, Group, Separator, Slot};
use yew::prelude::*;

#[function_component(VerificationInput)]
pub fn verification_input() -> Html {
    html! {
        <Otp max_length={6} aria_label="Enter your OTP">
            <Group>
                <Slot index={0} />
                <Slot index={1} />
                <Slot index={2} />
            </Group>
            <Separator />
            <Group>
                <Slot index={3} />
                <Slot index={4} />
                <Slot index={5} />
            </Group>
        </Otp>
    }
}

That's it. Focus management, digit propagation, state aggregation, and ARIA attributes are all handled. You just compose slots.

The Invisible Input Trick

Here's the most important design decision in all of OTP RS: the <input> element that receives keyboard events is completely invisible.

Each Slot renders two layers:

An invisible <input> (via input-rs with otp_mode=true) that is position: absolute; inset: 0; opacity: 0. It captures all keyboard focus and input events.
A visible <span> that displays the digit character and the blinking caret.

This separates the input mechanics from the visual presentation, giving us full control over the slot's look without fighting browser defaults for <input> styling.

┌─────────────────────┐
│  Slot wrapper       │  ← position: relative; border; background; animation
│  ┌───────────────┐  │
│  │ <input>       │  │  ← absolute; opacity:0; captures keyboard events
│  └───────────────┘  │
│  <span>3</span>     │  ← visible character display
│  <span class=caret/>│  ← blinking caret (when active & empty)
└─────────────────────┘

The Invisible Input That Wasn't Actually Invisible

Here's a fun bug that bit us early on, hard.

The slot design described above only works if the CSS for the invisible input is applied as an inline style attribute, not as a CSS class attribute. The component originally passed the overlay CSS string to input_class, a prop that sets the HTML class="" attribute.

Browsers don't style elements based on CSS property strings stuck in the class attribute. They look up class names in stylesheets. So what we got instead of an invisible overlay was a white rectangle aggressively covering the entire OTP component, like a censored emoji on live TV.

The fix was to add an input_style: &'static str prop to input-rs in all three framework implementations, and apply it as style="{props.input_style}" on the bare otp_mode <input>. One line per framework. Six characters (_style vs _class). Three frameworks. Three PRs worth of suffering.

The Compiler Is Your Enemy (And Also Your Best Friend)

Let us count the ways Rust fought us this time.

Episode 1: Hook in a Macro

error[E0277]: the trait bound `impl Hook<Output = ...>: IntoPropValue<...>` is not satisfied

We tried calling use_state(...) inside an html! macro attribute. Yew forbids calling hooks anywhere except directly inside function component bodies. The macro expands to a closure, and hook calls need to be at the top level. Extracting use_state calls to let bindings before html! fixed it.

Episode 2: `Box::leak` and the `&'static str` Obligation

Dioxus and Leptos's input-rs props require &'static str. But our slot-specific strings like "Digit 3" are computed at runtime. The only way to produce a &'static str from a runtime String without pulling in a string interner is to Box::leak:

let label: &'static str = Box::leak(
    format!("Digit {}", index + 1).into_boxed_str()
);

Yes, this leaks memory on every slot render. Each Slot render leaks ~15 bytes. Is this ideal? No. Does it compile? Yes. Is it the correct long-term solution? The correct long-term solution is a Signal<String> prop type in input-rs, which is a future PR. For now: Box::leak and move on.

Episode 3: The `as` Cast That Broke Leptos

The Leptos view! macro cannot parse Rust cast expressions inline:

// This fails to parse inside view!:
validate_function=(|_: String| -> bool { true }) as fn(String) -> bool

The macro sees the as keyword and gets confused about what's a prop name vs. a type expression. The fix: extract to a let binding before the view! call:

let always_valid: fn(String) -> bool = |_| true;
// then inside view!:
validate_function=always_valid

Three lines in, five compilation cycles later. We hope this saves you ten minutes.

Episode 4: `String` vs `&str` in Dioxus `rsx!`

Dioxus's rsx! macro is strict about attribute types. When slot_class was a String, the macro would refuse:

expected `&str`, found `String`

format!("...", ...) produces a String. Dioxus attributes want &str. The same Box::leak pattern solved this too:

let slot_class: &'static str = Box::leak(
    format!("{} {}", ctx.variant.to_slot_class(), props.class).into_boxed_str()
);

Episode 5: The Inter-Group Focus Traversal Collision

Here is a fun brain teaser: what happens when you put two OTP components on the exact same page, and you start typing in the second one?
Well, since our slots were originally assigned hardcoded IDs like otp-slot-0, otp-slot-1, the moment you typed a character in the second instance, document.getElementById("otp-slot-1") would aggressively hijack focus and yank your cursor all the way back up to the first OTP component on the page.

The fix? Prefixing every slot ID with a unique instance_id minted from a global atomic counter (OTP_INSTANCE_COUNTER.fetch_add(1, Ordering::Relaxed)). Now every widget lives in its own perfectly scoped focus namespace, free from neighborhood turf wars.

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Across Leptos and Yew we noticed a bizarre issue: if you typed a character, erased it, and tried typing again, the <input> would refuse to update. Or if you filled the very last slot, the input component became "sticky" and refused to overwrite the final character.

The root cause was a classic Virtual DOM vs Physical DOM standoff. We were setting the internal state to "", but frameworks optimize their renders. Leptos input-rs used a one-way, read-once initialization for value=handle.0.get(). Yew assumed the string was already empty and ignored the reconciliation. Because the physical HTML <input> wasn't being forcefully synchronized, the raw DOM held onto the sticky character and choked out any new keystrokes.

We had to bypass the frameworks entirely and manually flush the physical DOM element inside the keyboard event handlers using raw Web APIs (input_ref.cast::<web_sys::HtmlInputElement>().unwrap().set_value("")). The lesson here? Sometimes the fastest way out of a reactive state desync is a direct, imperative smash to the physical DOM.

Keyboard Navigation

One of the more satisfying pieces: full keyboard navigation across slots.

Any character key → fills current slot, auto-advances focus to the next
Backspace → clears current slot; if already empty, goes to the previous slot
ArrowLeft → jumps to previous slot
ArrowRight → jumps to next slot
Tab → advances naturally (browser default, we don't intercept)

All of this is handled in the on_slot_keydown callback in the parent Otp component, which uses NodeRef (Yew) or the equivalent signal-based refs (Dioxus/Leptos) to imperatively .focus() the target input.

if key == "Backspace" && idx > 0 {
    // slot is already empty, go back
    if let Some(node) = slot_refs.get(idx - 1) {
        if let Some(input) = node.cast::<HtmlInputElement>() {
            let _ = input.focus();
        }
    }
}

No third-party focus-trap libraries. No jQuery. Pure DOM manipulation from Rust.

HOTP and TOTP Validation

OTP RS ships RFC 4226 (HOTP) and RFC 6238 (TOTP) implementations using totp-rs. The SHA-1 HMAC is hand-rolled using the standard iterative block compression algorithm:

pub fn validate_hotp(
    secret: &[u8],
    counter: u64,
    code: &str,
    digits: u32,
) -> Result<(), OtpValidationError> {
    let expected = hotp(secret, counter, digits);
    if expected == code { Ok(()) } else { Err(OtpValidationError::HotpMismatch) }
}

You can validate on complete:

let on_complete = Callback::from(move |code: String| {
    match validate_hotp(b"your-secret", 0, &code, 6) {
        Ok(()) => web_sys::console::log_1(&"Valid!".into()),
        Err(e) => web_sys::console::warn_1(&format!("{e:?}").into()),
    }
});

The hotp() function also lets you generate the expected code if you need to display a hint in development. For the HOTP example in the landing page, the valid code for secret JBSWY3DPEHPK3PXP at counter 0 is computed at runtime via hotp(b"JBSWY3DPEHPK3PXP", 0, 6), no hardcoding required.

Quick Setup

# Yew
cargo add otprs --features=yew

# Dioxus
cargo add otprs --features=dio

# Leptos
cargo add otprs --features=lep

# Cargo.toml
otprs = { version = "0.1", features = ["yew"] }

The component ships its own CSS as inline styles computed from Rust. No separate stylesheet needed.

Final Thoughts

Building OTP RS was a journey through the exact kind of subtle, cross-framework, cross-layer complexity that makes Rust Web development both rewarding and sometimes deeply frustrating. We fought the compiler more than once, discovered ways that browser defaults quietly break invisible design patterns, and shipped a Box::leak we're not entirely proud of.

But the result is solid: a composable, keyboard-navigable, RFC-compliant OTP input component that works identically across Yew, Dioxus, and Leptos, with zero JavaScript and enough ARIA to satisfy a WCAG auditor.

The next time you're building a login flow in Rust WASM and you reach for a six-box code input, you don't have to write it from scratch anymore.

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible OTP (One-Time Password) input component for WASM frameworks: Yew, Dioxus, and Leptos.

Supports animated per-slot digit entry with automatic focus traversal, primary and secondary visual variants, built-in HOTP/TOTP validation per RFC 4226 and RFC 6238, and full WCAG compliance.

🤔 Why OTP RS?

🎨 Fully Customizable: Control every attribute, class, style, variant, pattern, ARIA labels and more, on the outermost container, each group, each slot, and each separator.
⌨ Smart Focus Management: Typing a digit automatically advances focus. Backspace regresses focus. Arrow keys navigate left and right.
✨ Animated Entry: Each digit pops with a scale animation when entered, and a blinking caret is shown in the active empty slot.
🔐 Built-in Validation: Validate against HOTP (RFC 4226) or TOTP (RFC 6238) using a pure-Rust implementation, no C, no…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

📋 Form RS: Production-Ready Form Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:25 +0000

Salut 👋!

If there's one thing that unites frontend developers across every language, framework, and decade of web history, it's a deep, personal, somewhat traumatic relationship with HTML forms.

You know the drill. You write a <form>. You add an <input>. You add a <label>. You write the JavaScript to validate it on blur. You add a <p> for the error message. You wire up aria-describedby so screen readers can find the error. You set aria-invalid on the input. You set aria-required. You check event.preventDefault(). You realize you've been writing a custom form library for the last four hours. You consider leaving the industry.

That stops today. We're shipping Form RS.

What Is Form RS?

Form RS is a fully composable, WCAG 2.2 AA compliant, production-ready form component library for Yew, Dioxus, and Leptos. It wraps Input RS for the actual <input> rendering, provides a complete context-driven architecture for validation state propagation, and ships seven discrete components that you can mix freely.

Think of it as the form library you would build yourself if you had time, patience, and hadn't already burned both writing <div class="form-group"> for the 8000th time.

The Seven Components

Form RS ships a composable hierarchy, not a monolith.

`Form`

The outermost container. Wraps <form> with configurable method, action, enctype, autocomplete, ARIA labels, and submit/reset/invalid callbacks. There are two validation modes:

ValidationBehavior::Native   // HTML5 + browser popups (default)
ValidationBehavior::Aria     // Real-time ARIA errors, no popups, submit never blocked

`Control`

The context provider. Wraps a single field, distributes disabled, error, focused, required, variant, color, and size state to every child that reads FormControlContext. Your labels and helper text automatically inherit this state without prop drilling.

`Label`

Renders a <label> that visually and semantically tracks the control's state. It goes red when there's an error. It glows when focused. It shows the required asterisk automatically. You don't have to think about any of this.

// In Yew:
<Label html_for="email" error={true} focused={false}>
    {"Email address"}
</Label>

`Helper`

A <p> element below the input. Changes color based on validation state:

<Helper error={true}>{"Not a valid email."}</Helper>
<Helper valid={true}>{"Looks great!"}</Helper>

Three states, zero class strings.

`Group`

Groups related checkboxes or radio buttons in a <fieldset>-adjacent <div>. The row prop flips the layout from column to horizontal. The aria_label wires up a role="group" for screen readers.

`ControlLabel`

Wraps a form control (checkbox, radio, switch) with its associated label text. Controls label placement (End, Start, Top, Bottom), required asterisks, and disabled styling.

<ControlLabel
    control={html! { <input type="checkbox" /> }}
    label={html! { <span>{"Email notifications"}</span> }}
    label_placement={LabelPlacement::End}
/>

`Field`

This is the one you'll use most. A drop-in composition of Control + Label + Input + Helper with reactive focus rings, error/valid ring states, ARIA attributes, and helper text management.

<Field
    id="email"
    label="Email address"
    r#type="email"
    placeholder="ferris@opensass.org"
    helper_text="Enter a valid email."
    required=true
    full_width=true
    handle={email.clone()}
    valid_handle={email_valid.clone()}
    validate_function={Callback::from(validate_email)}
/>

One component. Fully wired. WCAG compliant. You're done.

Validation Architecture

Form RS supports two distinct validation paradigms:

Native HTML5 Validation

Uses browser-native required, pattern, minlength, maxlength, and type="email" constraints. The browser handles error messages. Form submission is blocked on invalid fields. This is the ValidationBehavior::Native default.

External/ARIA Validation

Pass a ValidationState explicitly, from a server response, a complex cross-field rule, or your own logic:

ValidationState::None        // No judgment, untouched
ValidationState::Valid       // Green ring, success helper text
ValidationState::Invalid(msg)// Red ring, error helper text, aria-invalid="true"

Server errors? Set validation_state={ValidationState::Invalid("Email already in use.".into())} on the field. The error surfaces immediately. The ARIA is correct. Done.

Accessibility Built In

This isn't "we added aria-label" accessibility. This is the real thing.

Every Field generates a unique {id}-helper element ID and passes it as aria-describedby on the underlying <input>.
aria-required and aria-invalid are set precisely based on prop + validation state, not just "always true".
Helper renders with role="alert" when in error state, so screen reader users hear errors without tabbing to them.
Label is always linked to its input via for/html_for. No floating labels that break semantics.
Group propagates role="group" with aria-label for checkbox/radio clusters.

Audit-passing HTML forms. In Rust. Across three WASM frameworks.

The `ValidationState` Pattern

This is the piece that makes server-side validation ergonomic:

pub enum ValidationState {
    None,
    Valid,
    Invalid(String),
}

Pass None on a fresh field. Pass Valid once you've confirmed on the backend. Pass Invalid with your error message string when the server rejects it. The component does the rest.

Variant, Color, and Size System

Form RS exposes a full semantic token system for the input appearance:

// Visual input style
Variant::Outlined  // Default, bordered input box
Variant::Filled    // Solid filled background
Variant::Standard  // Bottom-border only

// Accent color (rings, labels, helper text)
Color::Primary | Color::Secondary | Color::Error | Color::Info | Color::Success | Color::Warning

// Input density
Size::Small | Size::Medium

Building a dense admin data-entry form? Size::Small. Consumer onboarding flow? Size::Medium. Dark theme with error highlights? Color::Error. The system handles the visual output; you just name the intent.

Quick Setup

Stop writing raw HTML form boilerplate. Do this:

# Yew
cargo add form-rs --features=yew

# Dioxus
cargo add form-rs --features=dio

# Leptos
cargo add form-rs --features=lep

Final Thoughts

Forms are foundational. Every user interaction that matters, login, registration, checkout, profile editing, contact, search, flows through a form. Getting them right means getting ARIA right, validation right, focus state right, and error surfacing right. Every time. On every field.

Form RS is the answer to "who has time for all of that." We did. You don't have to.

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible form component library for WASM frameworks: Yew, Dioxus, and Leptos. Supports HTML5 and ARIA validation, composable sub-components (Form, Control, FormLabel, Helper, Group, ControlLabel, Field), and full WCAG 2.2 AA compliance.

🤔 Why Form RS?

🎨 Fully Customizable: Control variant, color, size, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Mix Form, Control, FormLabel, Helper, Group, ControlLabel, and Field independently or together.
✅ Dual Validation: Supports native HTML5 validation and real-time ARIA error messaging.
♿ Accessible by Default: aria-describedby, aria-required, aria-invalid, and role="alert" wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:17 +0000

Privyet 👋!

You know that moment when you paste a <pre><code> block into your app and it looks like it was styled in 2003 by someone who had just discovered color: green? No theme. No copy button. No language badge. Just raw, uncolored text sitting in a box that someone called "good enough"?

Yeah. We fixed that. Today we're shipping Code RS.

What Is Code RS?

Code RS is a production-ready, fully-themed, accessible code display component for Yew, Dioxus, and Leptos. It does everything the ecosystem was missing:

Inline <Code>: colored, sized, variant-aware, with ARIA semantics.
<Block>: a composable container with header, title, language badge, copy trigger, and scrollable content area.
Pure-Rust syntax highlighting: zero CDN, zero JavaScript, compiles to clean WASM, 20+ languages.
8 built-in themes: OneDark, Dracula, NightOwl, GitHub Dark/Light, Solarized, Monokai, Nord, all switchable via a single theme prop.

No Prism.js. No highlight.js. No 10MB script tag loaded from a CDN you definitely trust completely. Just Rust, bytes, and inline style= spans.

The Big Idea

Here's the thing about syntax highlighting in WASM apps: every existing solution assumes JavaScript. Prism.js needs a DOM. highlight.js needs a runtime. Shiki needs Node. Tree-sitter is great, but it weighs as much as a sedan.

So we wrote our own.

The highlight_code(code, lang, theme) function in common.rs is a hand-rolled, char-by-char tokenizer that handles:

Block comments (/* */), single-line comments (//, #, --)
Double/single-quoted strings and JS template literals
Hex and float number literals with suffixes (0xFF, 1.0f32)
Rust macros (println!, vec!)
Python/CSS decorators (@dataclass, @media)
HTML tag names (<div>, </span>)
PascalCase → type, ALL_CAPS → constant, ident( → function call
Language-specific keyword sets (Rust, Python, TypeScript, SQL, Bash, 16 more)

All token spans get inline style= attributes from the chosen theme. No CSS classes. No external stylesheet. Just <span style="color:#c678dd;font-weight:600">fn</span>, and it works everywhere, including iframes and shadow DOM.

use coders::{Language, Theme, highlight_code};

let html = highlight_code(
    "fn main() {\n    println!(\"Hello!\");\n}",
    Language::Rust,
    Theme::Dracula,
);
// → "<span style="color:#ff79c6;font-weight:600">fn</span> ..."

Components

`Code`

The simplest unit. A <code> element with color, variant, and size props.

// Yew
html! {
    <Code color={Color::Accent} variant={Variant::Subtle} size={Size::Sm}>
        {"console.log(\"Hello, world!\")"}
    </Code>
}

Variants work exactly as you'd expect from the rest of Open SASS Kit: Solid, Subtle, Outline, Surface, Plain. Colors are the full palette: Default, Red, Orange, Yellow, Green, Teal, Accent, Pink, Success, Warning, Danger, and Custom("your-inline-css").

`Block`

// Leptos
view! {
    <Block
        code="fn main() {\n    println!(\"Hello!\");\n}"
        language={Language::Rust}
        theme={Theme::NightOwl}
    >
        <Header>
            <Title>"main.rs"</Title>
            <LanguageBadge />
            <CopyTrigger />
        </Header>
        <Content />
    </Block>
}

The Block pushes a BlockContext containing code, language, and theme into a provider tree. All child components read from context. Content calls highlight_code and injects the result via inner_html / dangerous_inner_html / Html::from_html_unchecked, the framework-appropriate unsafe-but-correct escape hatch for pre-rendered HTML. No prop drilling. No callback chains. Just context.

8 Themes

Theme	Background	Vibe
`OneDark`	`#1a1a2e`	The classic. Atom's gift to the world.
`Dracula`	`#282a36`	Halloween every day. Pink keywords.
`NightOwl`	`#011627`	Deep blue, warm salmon numbers.
`GithubDark`	`#0d1117`	Feels like GitHub, because it is.
`GithubLight`	`#ffffff`	For those who dare use light mode.
`Solarized`	`#002b36`	Ethan Schoonover's gift to the terminal.
`Monokai`	`#272822`	The Sublime Text nostalgia trip.
`Nord`	`#2e3440`	Arctic. Clean. Borderline peaceful.

Switch themes at runtime by simply changing the theme prop. The ThemeColors struct drives inline style generation, every push_span() call pulls the exact CSS value from the active theme's fields.

Need your brand colors? Theme::Custom(ThemeColors { keyword: "color:#ff0099;font-weight:600", ... }) and you're done.

The Build Journey

We are not going to pretend this was a relaxing weekend project. Here is an honest accounting.

Chapter 1: The Rust 2024 Edition

Rust Edition 2024 changed how string-like identifiers in macro positions are parsed. The yew::html! macro started rejecting class names like text-black and whitespace-pre, specifically the hyphen-adjacent tokens that look like prefix expressions.

The error: prefix 'black' is unknown. The fix: add a trailing space after the class name. Simple, but it wasted an embarrassing amount of time because the error message looks nothing like what it actually is.

// Before (breaks in Edition 2024):
class="flex text-black"
// After:
class="flex text-black "  // ← single space, problem solved

Chapter 2: Dioxus RSX

The rsx! macro in Dioxus parses string prop values as format strings. So this:

code: "fn main() {\n    println!(\"Hello!\");\n}"

Explodes with Failed to parse formatted segment: Expected Ident or Exp. Because { inside a string prop is format syntax to Dioxus, not a literal curly brace.

The fix: extract all code strings to const:

const HELLO_WORLD: &str = "fn main() {\n    println!(\"Hello!\");\n}";

rsx! {
    Block { code: HELLO_WORLD }
}

Unglamorous? Yes. But it compiles.

Chapter 3: The `dangerous_inner_html`

In Dioxus, dangerous_inner_html takes ownership of a String. In Leptos, inner_html takes a &str. In Yew, Html::from_html_unchecked takes an AttrValue. Three frameworks, three signatures, three slightly different ways to inject a pre-rendered HTML string.

Each one worked fine once you knew the exact type expected. Getting there required reading the framework source, not the docs, because the docs had helpfully omitted the borrow semantics.

Chapter 4: Non-Exhaustive `Variant::Custom`

Adding Custom(&'static str) to the Variant enum immediately broke every match in all three Code component implementations. Expected. Annoying. The fix is the following:

Variant::Custom(_) => "",

But finding all three match sites across three files while also trying to fix four other things simultaneously is exactly the kind of thing that makes you wish Rust had #[non_exhaustive] as an opt-in marker you could flip during development.

Accessibility

Code RS ships accessible markup out of the box:

Block renders as <figure role="region"> with aria-label.
The inner <pre> gets tabindex="0" so keyboard users can scroll it.
CopyTrigger carries aria-label="Copy code to clipboard" and aria-live region feedback via the copied label swap.
Code accepts aria_label for use in contexts where <code> alone doesn't carry enough meaning.
LanguageBadge reads the language from context and renders aria-label="Language: rust".

Screen readers don't need to guess what anything is.

Quick Setup

# Yew
cargo add coders --features=yew

# Dioxus
cargo add coders --features=dio

# Leptos
cargo add coders --features=lep

That's it. The syntax highlighting, theming, clipboard, and accessibility, all included. No config files. No CSS imports. No npm install @something/highlighter-peer-dependency.

Final Thoughts

Writing a CDN-free, pure-WASM syntax highlighter from scratch to ship alongside a composable code block component is not the most efficient path. But it's the correct one for this ecosystem.

The web has enough <script src="https://cdn.example.com/dep.min.js"> tags. Rust WASM doesn't need to inherit that habit.

Code RS compiles to WASM, highlights code inline, and ships 8 themes without a single network request beyond your app bundle. That's the promise.

opensass / coders

💻 A highly customizable code component for WASM frameworks.

💻 Code RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible inline code and code-block component for WASM frameworks: Yew, Dioxus, and Leptos. Supports multiple colors, variants, sizes, copy-to-clipboard, and composable sub-components, all WCAG compliant.

🤔 Why Code RS?

🎨 Fully Customizable: Control every attribute, class, style, color, variant, size, ARIA labels, and more.
📋 Copy to Clipboard: Built-in copy button with a configurable confirmation label and reset timeout.
🧩 Composable: Compose Header, Title, CopyTrigger, Content, and LanguageBadge independently.
♿ Accessible by Default: role="region", aria-label, aria-live and tabindex wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🃏 Card RS: Extremely Customizable Card component for WASM frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:11:08 +0000

Salut tout le monde 👋!

If there is one layout component that has been re-implemented more times than the <button>, it's the Card. Think about it. Every widget, every dashboard panel, every pricing tier, every shiny glowing glassmorphism element you've ever seen is, deep down, a card.

Instead of writing div class="p-6 border rounded-xl shadow-lg bg-white" for the 5000th time, we decided to solve cards natively for WASM.

Today, we're shipping Card RS.

What Is Card RS?

Card RS is an extremely customizable, production-ready, accessible Card component for Yew, Dioxus, and Leptos. We've extracted all the tedious BEM boilerplate, flexbox wrangling, and ARIA attributes out of your templates, giving you a clean, composable API for building solid UI surfaces.

Cards shouldn't be monoliths. If you just need a surface, <Card> works perfectly alone. If you need standard anatomical parts, stick <Header>, <Title>, <Content>, and <Footer> in there.

The Composable Anatomy

The problem with most UI library cards is that they force you into a specific layout. Card RS doesn't mandate structure; it provides logical boundaries.

The Shell: `Card`

The parent wrapper. It renders a clean HTML5 <article> (or whatever ARIA role you need) with our default elevated styling.

use card_rs::yew::Card;
use card_rs::Variant;
use yew::prelude::*;

#[function_component(MyWidget)]
pub fn widget() -> Html {
    html! {
        <Card variant={Variant::Default} aria_labelledby="widget-title">
            // the world is yours in here
        </Card>
    }
}

The Skeleton: Headers, Content, & Footers

Don't want to write inline styles for gaps and flex-columns? Neither do we.

<Card aria_labelledby="c-title">
    <Header>
        <Title id="c-title">{"Card Title"}</Title>
        <Description>{"The description lives here."}</Description>
    </Header>
    <Content>
        <p>{"Any content fits neatly in the main body area."}</p>
    </Content>
    <Footer>
        <button aria-label="Confirm">{"Confirm"}</button>
    </Footer>
</Card>

The header stacks title and description with precise spacing. The footer handles your action bars. Everything just snaps into place like LEGOs.

Variants and Prominence

Not all cards are created equal. You need visual hierarchy. We provide a Variant matrix that affects the surface depth and contrast without rewriting class strings.

pub enum Variant {
    Transparent,  // No background, merges with the canvas
    Default,      // Standard surface layer
    Secondary,    // Elevated and highlighted
    Tertiary,     // Premium prominence (perfect for selected items)
}

Building an interactive pricing selector? Wrap your iterations in a <Card variant={if selected { Variant::Secondary } else { Variant::Default }}> and your hierarchy logic is done.

Framework Parity

Like everything we build, Card RS provides identical API surfaces and behavioral guarantees across all three rusty frontends:

Feature	Yew	Dioxus	Leptos
`Card`	✅	✅	✅
`Header`	✅	✅	✅
`Title` & `Description`	✅	✅	✅
`Content` & `Footer`	✅	✅	✅
Variant Matrix	✅	✅	✅
Accessible ARIA bindings	✅	✅	✅
Role overrides	✅	✅	✅

If you know how to build a card in Leptos, you can build a card in Dioxus. The props are the same. The BEM classes are the same. The logic is identical.

Accessibility Built-In

Accessible surfaces are often completely ignored by developers until an audit fails. Card RS is designed strictly around WCAG guidelines.

Card renders with role="article" by default.
We enforce aria_labelledby to tie structural landmarks to the Title ID.
If you want a non-interactive surface, just override it with role="note" or role="region".

// Accessible structural linking:
<Card aria_labelledby="promo-heading" role="region">
    <Header>
        <Title id="promo-heading">{"Special Offer!"}</Title>
    </Header>
</Card>

With one prop, screen readers will now announce "Region: Special Offer!" properly.

Customization

We aren't trapping you in our aesthetic. Want a weird horizontally-aligned flex-row card with a gradient background? Just use the style prop. Card RS accepts your CSS strings eagerly.

Quick Setup

Stop copying and pasting giant Tailwind HTML blobs. Do this instead:

# Yew
cargo add card-rs --features=yew

# Dioxus
cargo add card-rs --features=dio

# Leptos
cargo add card-rs --features=lep

Final Thoughts

The web is made of cards. Taking the time to unify how we create, structure, and render them across Wasm frameworks means we can stop fighting with padding and flexbox alignment, and get back to building real features.

opensass / card-rs

🃏 A highly customizable card component for WASM frameworks

🃏 Card RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible card component for WASM frameworks: Yew, Dioxus, and Leptos. Supports semantic prominence variants, composable sub-components (header, title, description, content, footer), and full WCAG compliance.

🤔 Why Card RS?

🎨 Fully Customizable: Control variant, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Use Card, Header, Title, Description, Content, and Footer independently or together.
🏷️ Semantic Variants: transparent, default, secondary, tertiary, themes interpret prominence without hard-coded colors.
♿ Accessible by Default: role="article", aria-labelledby, and aria-label wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🔴 Badge RS: Easy to Use Badge Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:08:44 +0000

Je vous salue 👋!

Every WASM app eventually needs a badge. The little red circle on your notification bell. The green dot on the corner of an avatar. The "99+" that taunts you every morning from the inbox icon. They're everywhere, and somehow everyone is still hand-rolling them.

That stops today. We're shipping Badge RS.

What Is Badge RS?

Badge RS is a production-ready badge component for Yew, Dioxus, and Leptos. Notification counters, status dots, overflow labels, the whole catalogue. It handles positioning, sizing, color theming, dot mode, accessible markup, and even knows the difference between a circle and a rectangle.

If you've ever opened your browser devtools at 11pm trying to figure out why a badge is floating 4px off the corner of an avatar instead of sitting flush on the arc, Badge RS is the component you wish had existed.

The Core Components

`Anchor`

The positioning wrapper. Drop it around any element and it becomes a badge target. Uses position: relative; display: inline-flex; so it doesn't break your layout, doesn't eat your accessibility tree, and doesn't require you to memorize any CSS tricks.

use badges_rs::yew::{Badge, Anchor};
use badges_rs::{Color, Shape};
use yew::prelude::*;

#[function_component(NotificationBell)]
pub fn notification_bell() -> Html {
    html! {
        <Anchor>
            <span aria-label="Inbox, 5 unread messages">{"📬"}</span>
            <Badge
                color={Color::Danger}
                shape={Shape::Circle}
                aria_label="5 unread messages"
            >
                {"5"}
            </Badge>
        </Anchor>
    }
}

That's it. The badge positions itself. You decide where.

`Badge`

The actual indicator. Pass children and you get a labeled badge with text inside. Skip children and you get a compact do, no extra prop needed, just don't put anything inside.

// A labeled count badge
<Badge color={Color::Danger} size={Size::Sm} aria_label="5 unread">{"5"}</Badge>

// A status dot, no children, no extra prop
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

Same component, two modes. The dot is not a separate component.

`BadgeLabel`

A thin <span class="badge__label"> wrapper. Used automatically when you pass plain text to Badge. Expose it directly when you need extra CSS classes or styling on the label slot.

Colors, Variants, Sizes

The full set of knobs is available:

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger

// Variants (three visual styles)
Variant::Primary    // solid fill
Variant::Secondary  // outlined
Variant::Soft       // muted, lower-contrast

// Sizes
Size::Sm | Size::Md | Size::Lg

// Placement
Placement::TopRight | Placement::TopLeft | Placement::BottomRight | Placement::BottomLeft

All combinations work. TopLeft is there for RTL layouts and anyone who likes to be contrarian about badge placement.

The Positioning Bug Nobody Talks About

Here's the subtle one. top: 0; right: 0 with transform: translate(50%, -50%) centers a badge perfectly on the corner of a rectangle. That's fine for icon buttons, list items, or anything with a square bounding box.

For a circle, which is what every avatar in existence is, the story is different. A circle's actual edge at 45° sits inward from the bounding box corner. The geometric offset is exactly 1 - sin(45°), which works out to roughly 14.64% of the element's width and height.

Most badge implementations ignore this. The badge floats slightly off the arc, nobody files a bug, and the designer quietly seethes.

Badge RS exposes a Shape enum to handle this explicitly:

pub enum Shape {
    Rectangle,  // top: 0; right: 0, standard bounding box corner
    Circle,     // top: 14.64%; right: 14.64%, sits on the arc
}

// On a circular avatar, badge sits flush on the arc:
<Badge color={Color::Danger} shape={Shape::Circle} aria_label="3">{"3"}</Badge>

// On a square icon button, badge sits on the bounding box corner:
<Badge color={Color::Accent} shape={Shape::Rectangle} aria_label="New">{"New"}</Badge>

The math is not magic. It's just trigonometry that nobody wanted to look up at 11pm. We looked it up for you.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Anchor`	✅	✅	✅
`Badge`	✅	✅	✅
`BadgeLabel`	✅	✅	✅
`Shape::Circle` offset	✅	✅	✅
Dot mode (no children)	✅	✅	✅
All placements	✅	✅	✅
All variants	✅	✅	✅
ARIA attributes	✅	✅	✅

If you've used it in Yew, you already know how to use it in Dioxus and Leptos. The prop names don't even change.

Accessibility

Accessible badges are an afterthought in most libraries. In Badge RS they're mandatory.

Badge renders with role="status" and a required aria_label. Screen readers announce the content without the user having to navigate to it.
aria-atomic="true" ensures the full label is re-read when the count updates. A badge that goes from "3" to "4" reads "4 unread messages", not just "4".
Anchor renders as a <span> with no ARIA role, because it's structural glue and should be invisible to assistive technology.
The WCAG guidance on badges is straightforward: label the element that owns the badge, not just the badge itself. We mention this in the docs and the examples follow it throughout.

// The accessible way, the host element's label includes the count
<span aria-label="Inbox, 5 unread messages">{"📬"}</span>
<Badge aria_label="5 unread messages">{"5"}</Badge>

The badge label and the host's aria-label should tell the same story from different angles.

Quick Setup

# Yew
cargo add badges-rs --features=yew

# Dioxus
cargo add badges-rs --features=dio

# Leptos
cargo add badges-rs --features=lep

No CSS framework required. Styles are computed inline from the prop values.

Dot Mode vs Count Mode

One component, two modes, no separate component for each. This matters because it keeps your import surface small and your mental model consistent.

// Count mode, children present
<Badge color={Color::Danger} aria_label="5 messages">{"5"}</Badge>

// Dot mode, no children, badge renders as a small filled circle
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

The dot is a first-class mode with its own size calculations. Size::Sm in dot mode renders a 6×6px dot. In count mode, it renders a 16×16px pill. The size label refers to the visual weight, not a fixed pixel value.

Status Indicators

The placement prop combined with dot mode covers the most common avatar status pattern:

use badges_rs::leptos::{Badge, Anchor};
use badges_rs::{Color, Placement, Shape};
use leptos::prelude::*;

#[component]
pub fn UserAvatar() -> impl IntoView {
    view! {
        <Anchor>
            <span
                style="/* your avatar CSS */"
                aria-label="Jane Doe, online"
            >
                "JD"
            </span>
            <Badge
                color=Color::Success
                shape=Shape::Circle
                placement=Placement::BottomRight
                aria_label="Online"
            />
        </Anchor>
    }
}

Green dot, bottom-right, perfectly on the arc. That's the whole pattern.

What We Didn't Do

No magic threshold that auto-truncates to "99+". That's application logic, not component logic. We show whatever you pass in. If you want count.min(99).to_string() or "99+", that's two lines in your own code.

No auto-detection of the parent element's shape. That would require measuring the DOM at runtime, which is expensive. Instead: explicit shape prop. You know your own design system. Tell us.

No CSS injection. No global stylesheet to import. No BEM class naming conventions to memorize. The styles live on the element.

Final Thoughts

Badge RS is compact by design. Three components, one enum, one positioning decision that most libraries get wrong.

The Shape prop is the detail worth remembering. If you're putting badges on circular avatars and they look slightly off, that's the fix. Try Shape::Circle and stop adjusting pixel offsets in your component stylesheets.

opensass / badges-rs

🏷️ A highly customizable badge component for WASM frameworks.

🏷️ Badges RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible badge component for WASM frameworks: Yew, Dioxus, and Leptos. Supports notification counts, status dots, labels, multiple colors, variants, sizes, and placements with full WCAG compliance.

🤔 Why Badges RS?

🎨 Fully Customizable: Control color, variant, size, placement, class, style, and ARIA labels.
🔴 Dot Mode: When no children are provided the badge renders as a compact status dot.
📍 Smart Placement: Four corner placements (top-right, top-left, bottom-right, bottom-left) via CSS transform for pixel-perfect positioning.
♿ Accessible by Default: role="status", aria-label, and aria-atomic wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🪪 Avatar RS: Very Efficient Avatar Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:01:40 +0000

Bien le bonjour 👋!

Every WASM app eventually needs an avatar. Profile pictures, user cards, comment threads, they're everywhere. And every time, developers end up rolling the same <img> tag with some fallback logic, hardcoded border-radius, and a prayer that the CDN doesn't return a 404.

That stops today. We're shipping Avatar RS.

What Is Avatar RS?

Avatar RS is a fully-featured avatar component for Yew, Dioxus, and Leptos. It handles image loading, fallback text/icons, overflow groups, color themes, size variants, accessible markup, the whole thing. Built on top of Image RS, which means you get smart lazy loading, blur-up placeholders, and responsive layouts for free.

Think of it as the avatar component you'd build if you had infinite time and zero deadlines. We had neither, but here we are anyway.

The Stack Under the Hood

Avatar RS wraps Image RS, our WASM-native image primitive, for the actual <img> element. This is not a trivial detail.

Image RS uses Intersection Observer API for lazy loading, supports srcset/sizes for responsive images, and fires clean on_load / on_error callbacks. All of that comes for free inside every Image you render. The avatar layer only adds context management and state coordination on top.

Core Components

`Avatar`

The container. Wraps Image and Fallback, provides the shared loading context, and inherits size/color/variant from a surrounding Group if present.

use avatar::yew::{Avatar, Image, Fallback};
use avatar::Color;
use yew::prelude::*;

#[function_component(MyProfile)]
pub fn my_profile() -> Html {
    html! {
        <Avatar aria_label="Ferris Prophet">
            <Image
                src="https://i.pravatar.cc/300"
                alt="Ferris Prophet"
            />
            <Fallback color={Some(Color::Accent)}>{"JD"}</Fallback>
        </Avatar>
    }
}

The fallback shows while the image loads, hides once it lands.

`Fallback`

Text initials, an icon, or anything you want rendered when the image hasn't loaded yet (or doesn't exist at all). Supports a delay_ms prop to intentionally delay reveal, useful when your image usually loads fast and you don't want the fallback to flash briefly then disappear.

// Fallback shows immediately:
<Fallback color={Some(Color::Success)}>{"MH"}</Fallback>

// Fallback waits 200ms before appearing (prevents flicker on fast connections):
<Fallback delay_ms={200} color={Some(Color::Accent)}>{"JD"}</Fallback>

Small prop, big UX difference.

`Group`

Stack multiple avatars with automatic overlap, configurable max count, and an overflow badge showing how many more there are.

use avatar::yew::{Avatar, Group, Count, Image, Fallback};
use avatar::{Color, Size, Variant};
use yew::prelude::*;

#[function_component(TeamStack)]
pub fn team_stack() -> Html {
    html! {
        <Group
            size={Size::Lg}
            max={Some(3)}
            total={Some(6)}
            aria_label="Project team"
        >
            <Avatar aria_label="Member 1">
                <Image src="https://i.pravatar.cc/150?u=m1" alt="Member 1" />
                <Fallback color={Some(Color::Accent)}>{"M1"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 2">
                <Image src="https://i.pravatar.cc/150?u=m2" alt="Member 2" />
                <Fallback color={Some(Color::Success)}>{"M2"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 3">
                <Image src="https://i.pravatar.cc/150?u=m3" alt="Member 3" />
                <Fallback color={Some(Color::Warning)}>{"M3"}</Fallback>
            </Avatar>
            <Count
                color={Some(Color::Danger)}
                variant={Some(Variant::Soft)}
                aria_label="3 more members"
            />
        </Group>
    }
}

Pass max={Some(3)} and total={Some(6)}, and Count automatically shows +3. The math is done for you. The CSS overlap is done for you. You just write components.

The `overflow_count` Context

This is the part that required actual thought.

Group computes overflow_count = total - max and pushes it into context. Count reads it from context when its own count prop is zero (the default). This means the badge doesn't need to know anything explicit, it just reads the group state.

// In Group:
let overflow_count = total.saturating_sub(max);
ctx_provider.provide(&GroupContext { overflow_count, .. });

// In Count:
let effective_count = if count == 0 { ctx_overflow } else { count };
// Renders: "+{effective_count}"

One source of truth.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Avatar`	✅	✅	✅
`Image`	✅	✅	✅
`Fallback`	✅	✅	✅
`Group`	✅	✅	✅
`Count`	✅	✅	✅
`total` + `max` overflow	✅	✅	✅
Context propagation	✅	✅	✅
`delay_ms` on fallback	✅	✅	✅
Image RS integration	✅	✅	✅

The Dioxus and Leptos implementation uses use_context_provider / use_context idioms native to each framework, but the behavior is identical. If you've used it in Yew, you already know how to use it in Leptos.

Soft Refresh & The Browser Cache Fix

Here's one that caught us off guard. In Yew, images rendered via Image would sometimes fail to appear after a soft page refresh. Hard refresh? Fine. Soft? Gone.

The culprit: when a browser serves an image from cache, the load event fires before Yew has had a chance to attach the listener. The effect sees a "loading" state, the image is already done, and the component never flips to "loaded".

The fix was straightforward once we knew what to look for. We inject a node_ref into the underlying <img> element and check img.complete on mount:

use_effect_with(props.src, move |src| {
    if !src.is_empty() {
        let already_loaded = node_ref
            .cast::<web_sys::HtmlImageElement>()
            .map(|img| img.complete())
            .unwrap_or(false);

        if already_loaded {
            status.set(ImageLoadingStatus::Loaded);
        } else {
            status.set(ImageLoadingStatus::Loading);
        }
    }
    || ()
});

This required adding web-sys with the HtmlImageElement feature to the yew feature gate in Cargo.toml. A small addition, but it closes a genuinely annoying browser quirk.

Dioxus and Leptos did not have this issue, their reactive systems handle DOM updates differently and don't suffer from this ordering problem.

Colors, Variants, Sizes

Everything inherits downward through context. Set defaults at the group level, override them per-avatar if needed.

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger | Color::Custom("...")

// Variants
Variant::Default  // solid fill
Variant::Soft     // muted, lower-contrast

// Sizes
Size::Xs | Size::Sm | Size::Md | Size::Lg | Size::Xl | Size::Xxl | Size::Custom("...")

Color::Custom("...") and Size::Custom("...") accept raw CSS strings, so if your design system uses hsl(270 60% 50%) or 3.5rem, those work too.

Quick Setup

# Yew
cargo add avatar --features=yew

# Dioxus
cargo add avatar --features=dio

# Leptos
cargo add avatar --features=lep

That's it. The styling is computed inline from the prop values.

Accessibility

Every component exposes its ARIA props explicitly:

Avatar renders role="img" with a required aria_label.
Image manages aria-hidden based on loading state.
Fallback is hidden from assistive tech once the image loads.
Group gets an aria_label for the whole group.
Count gets its own aria_label (defaults to "Additional members").

Screen readers get a consistent, clear picture regardless of whether images loaded or not.

What We Didn't Do

No auto-injection of count badges. No magic child-slicing that differs between frameworks. No runtime diffing of the children list to figure out how many to show. These patterns break in different ways across Yew, Dioxus, and Leptos, and they make the component harder to reason about.

Instead: explicit total and max props, explicit Count placement, one context object that everything reads from. It's a little more to type. It's a lot easier to debug.

Final Thoughts

Avatar RS is exactly what it says on the tin: a production-ready avatar component for WASM apps.

It's backed by Image RS, which means you get all the image loading sophistication without reinventing it. The overflow logic is explicit and predictable. Framework parity is real, not aspirational.

opensass / avatar

👦 A highly customizable avatar component for WASM frameworks (Powered by Image RS).

👦 Avatar

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible avatar component for WASM frameworks: Yew, Dioxus, and Leptos. Supports image loading with automatic fallback content, multiple sizes, color themes, and full WCAG compliance.

🤔 Why Avatar?

🎨 Fully Customizable: Control every attribute, class, style, size, color, variant, ARIA labels and more.
🖼️ Smart Image Loading: Tracks idle → loading → loaded/error status with context. Fallback is shown until the image is ready.
⏱ Delay Support: Prevent flash-of-fallback on fast connections with delay_ms.
♿ Accessible by Default: role="img", aria-label, aria-hidden wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱 Leptos

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

I Resurrected a Dead CRC Crate and It Suddenly Went Viral

Mahmoud 🦀 — Sun, 20 Sep 2026 09:11:49 +0000

Bonjour 👋!

So there I was, browsing crates.io at an hour that most reasonable people would describe as "the middle of the night", doing what all emotionally stable developers do at that hour: auditing dead Rust crates for signs of life.

That's when I found crc32.

Not crc32fast. Not crc. Not crc32c. The original. The stubby, ancient, crc32 crate. Last published in 2015. No changelog. No CI. A Cargo.toml that predates most of the stable Rust syntax I use daily. And sitting there, abandoned and unloved.

People were using this thing. Were probably shipping software with it in their dependency tree. They just didn't know how to reach the crate maintainer, who had apparently retired to a cabin in the woods with no internet access sometime around when Rust 1.0 was announced.

I stared at those download numbers for thirty seconds.

Then I did what any emotionally stable rustacean would do: I resurrected it. From the ashes. In modern Rust. With no_std. With Python bindings. With a build-time proc-macro codegen crate. With CI/CD, Debian packaging, RPM packaging, and a Ferris logo.

You know. Normal stuff.

Wait, What Even Is CRC-32?

CRC-32 stands for Cyclic Redundancy Check, 32-bit variant. It's the checksum algorithm that:

ZIP files use to verify archive integrity.
Ethernet frames use to detect bit errors in transmission.
FDDI, PKZIP, PNG and approximately half the binary protocols ever invented also use.
Every zlib function you've ever called calls internally when you weren't paying attention.

In other words, CRC-32 is everywhere. It's the duct tape of data integrity. It's been computing checksums since before most of today's developers were handing in their first homework assignments.

The original Rust crc32 crate implemented the byte-at-a-time version, the classic, the grandaddy variant. Simple. Correct. Slow as a 56k modem by 2024 standards.

I didn't just port it. I rewrote the whole thing from the zlib source, added slicing-by-4, slicing-by-8, and slicing-by-16 table variants, pulled the table-generation itself into a build-time proc-macro subcrate, added a streaming Digest, a GF(2) matrix combine function, and shipped the whole thing as a no_std library with Python and Node.js bindings.

All in 100% safe Rust. With #![forbid(unsafe_code)] at the crate root.

Because anything worth resurrecting is worth resurrecting properly.

The Architecture

Let me tell you what the original crc32 crate looked like. It was, essentially:

src/lib.rs
src/crc32gen.rs
src/crc32gen_file.rs

That's it. 3 files. A lookup table, a loop, a bitwise XOR. Beautiful in its simplicity, like a stone hut in a field. Functional. Zero frills. Absolutely not capable of 1 GiB/s throughput.

Here's what crc32-v2 looks like today:

crc32-v2/
├── crc32-codegen/             ← proc-macro subcrate: generates all 17 CRC tables at build time
│   └── src/lib.rs             ← build.rs calls crc32_codegen::run() → writes to $OUT_DIR
├── src/
│   ├── lib.rs                 ← minimal entry point: #![no_std], module declarations, Python FFI
│   ├── tables.rs              ← crc32() byte-at-a-time baseline
│   ├── byfour.rs              ← crc32_little / _8 / _16 / crc32_big
│   ├── combine.rs             ← crc32_combine() via GF(2) matrix squaring in O(log n)
│   ├── digest.rs              ← streaming Digest with update() / finalize() / digest()
│   └── python.rs              ← PyO3 bindings (gated on feature = "python" + "std")
├── tests/
│   └── byfour.rs              ← 40 Rust integration tests
└── python/
    └── crc32_rs/
        └── __init__.py        ← re-exports all symbols from the compiled .so

The stone hut has been converted into a, uh, well-appointed facility.

The Magic Trick

This is my personal favourite part of the whole project. And possibly the most unhinged.

CRC-32 slicing-by-16 requires 17 lookup tables: one 256-entry big-endian table, and 16 256-entry little-endian tables at different offsets. That's 17 × 256 × 4 = 17,408 bytes of lookup table data that needs to exist at runtime.

The naive way: write the tables by hand and commit 17,000 bytes of constants to git as a .rs file.

The normal way: generate them at startup and cache them in a static.

The way I did it: proc-macro subcrate (crc32-codegen) that is invoked from build.rs at compile time, generates all 17 tables using the CRC-32 polynomial arithmetic, writes them to $OUT_DIR/crc_tables.rs, and the main crate include!s the output. Zero runtime initialization. Zero startup cost. The tables are baked into the binary at link time.

[build-dependencies]
crc32-codegen = { path = "crc32-codegen" }

fn main() {
    crc32_codegen::run();
}

That's the entire build.rs. One function call. The codegen crate does all the polynomial math, formats the Rust source, and writes it to disk. The main crate wakes up with all 17 tables pre-computed, pre-verified, and pre-formatted.

This is the kind of thing that inspires either awe or a mildly concerned Slack message from your coworkers. There is no middle ground.

The 4 Speeds of CRC-32

Let me paint you a picture of what "slicing-by-N" actually means, because it's one of those ideas that sounds arcane until you see the numbers and then you can't stop thinking about it.

The classic CRC-32 loop looks like this:

for &byte in buf {
    let index = (crc ^ u32::from(byte)) & 0xff;
    crc = CRC_TABLE[0][index as usize] ^ (crc >> 8);
}

One byte per iteration. One table lookup. On a 1 MiB payload that's 1,048,576 iterations. At ~2 ns per iteration (fast CPU, warm cache), that's ~2ms. Not terrible. Not great.

Slicing-by-4 says: what if we process four bytes per iteration instead? You pre-compute four separate 256-entry tables (one for each byte offset), and in each step you XOR together four table lookups instead of one. Four bytes per iteration, four table lookups, but modern CPUs can do all four lookups in parallel because there are no data dependencies between them. Result: roughly 2.4× faster.

Slicing-by-8 does the same with eight tables. Slicing-by-16 pushes it to sixteen tables and sixteen bytes per step, letting the CPU's out-of-order execution and instruction-level parallelism do the heavy lifting. With #[inline(always)] on the inner fold functions, fat LTO, and overflow-checks = false in the bench profile, LLVM sees through all the abstraction and generates machine code that is, frankly, embarrassingly fast for code written entirely in safe Rust.

The full breakdown:

Method	1 B	64 B	1 KiB	64 KiB	1 MiB	Throughput
`crc32` (byte-at-a-time)	2 ns	167 ns	2,856 ns	188,134 ns	2,916,562 ns	~343 MiB/s
`crc32_little` (slicing-by-4)	3 ns	73 ns	1,086 ns	82,129 ns	1,199,953 ns	~833 MiB/s
`crc32_little_8` (slicing-by-8)	3 ns	61 ns	922 ns	56,486 ns	1,004,746 ns	~1,004 MiB/s
`crc32_little_16` (slicing-by-16)	3 ns	39 ns	753 ns	48,101 ns	781,535 ns	~1,282 MiB/s
`crc32fast` (SIMD via `pclmulqdq`)	11 ns	20 ns	102 ns	5,802 ns	89,204 ns	~11,300 MiB/s

crc32_little_16 hits ~1,282 MiB/s on a 1 MiB payload. That's 3.7× faster than the baseline, without a single SIMD intrinsic, without a single unsafe block, and without any CPU feature detection. It Just Works on x86-64, ARM, RISC-V, WASM, and whatever exotic architecture you're running this week.

Note that tiny 1-byte payloads still favour the baseline crc32 (2 ns vs 3 ns) because the slicing variants pay a small alignment prologue overhead. We document this honestly, unlike some people's README files.

The Cross-Library Reality Check

Look. I know what you're thinking. "But crc32fast uses SIMD and does 11 GiB/s. Doesn't that make this pointless?"

No. Here's why.

crc32fast is genuinely excellent for x86-64 with pclmulqdq. But crc32-v2 occupies a different niche:

Library	Method	Time (1 MiB)	Throughput	Type
`crc32fast`	`hash`	89,204 ns	~11,300 MiB/s	SIMD (`pclmulqdq`) / Rust
`zlib-rs`	`crc32`	96,968 ns	~10,390 MiB/s	SIMD / Rust
Python (`zlib.crc32`)	C extension	355,270 ns	~2,815 MiB/s	SIMD / C
`crc32-v2`	`crc32_little_16`	781,535 ns	~1,282 MiB/s	Pure safe Rust
Python (`crcmod`)	C extension	2,865,836 ns	~349 MiB/s	Non-SIMD / C

crc32fast: amazing. zlib-rs: also amazing. Both use runtime SIMD dispatch and unsafe. Both don't compile to WASM without special handling. Both don't work in no_std environments without a careful dance.

crc32-v2 compiles everywhere Rust compiles. Embedded RISC-V? Yes. wasm32-unknown-unknown? Yes. A microcontroller that needs to verify a firmware checksum before flashing? Yes. A kernel module? With #![no_std] and a custom allocator? Also yes.

When you need 11 GiB/s you use crc32fast. When you need something that works anywhere, has zero dependencies outside alloc, and is produced by a compiler that will literally refuse to let you write unsafe code: you use crc32-v2. There are more situations in the second category than you'd expect.

Python Bindings

Here's a section I am writing in the spirit of radical honesty. Shipping Python bindings for a Rust library requires configuring:

maturin (the build tool)
pyo3 (the FFI framework)
pyproject.toml (the Python packaging config)
A python/crc32_rs/__init__.py that re-exports from the compiled .so
The module-name field in pyproject.toml matching the #[pymodule] name in Rust

If any one of these four things is even slightly wrong, Python greets you with:

ModuleNotFoundError: No module named 'crc32_rs'

Not a helpful error. Not "the module-name in pyproject.toml doesn't match the pymodule attribute". Just: it doesn't exist. Good luck.

I went through approximately four rounds of this before getting it right. The root cause was a mismatch between module-name = "crc32_v2._crc32_v2" (incorrect) and module-name = "crc32_rs._crc32_v2" (correct). One underscore in the wrong namespace and Python acts as if the entire compiled extension simply does not exist in this universe.

The fix took three characters. The investigation took forty-five minutes.

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest
>>> 
>>> print(hex(crc32(b"Hello, world!")))
0xebe6c6e6
>>> print(hex(crc32_little_16(b"Hello, world!")))
0xebe6c6e6
>>> print(crc32_bytes(b"Hello, world!").hex())
ebe6c6e6
>>> print(crc32_hex(b"Hello, world!"))
ebe6c6e6
>>> 
>>> d = Digest()
>>> d.update(b"Hello, ")
>>> d.update(b"world!")
>>> print(hex(d.finalize()))
0xebe6c6e6
>>> print(repr(d))
Digest(crc=0xEBE6C6E6)

Now it works. The Python interpreter is stuffed. We do not speak of the forty-five minutes.

Rust for Python Developers

Let's talk about something that the throughput benchmarks don't fully capture: what happens to performance when you're computing CRC-32 on tiny payloads? Like, really tiny. 1 byte tiny.

The issue with Python's zlib.crc32 is not that it's slow for large inputs, it delegates to SIMD C code under the hood and handles 1 MiB payloads at 2,815 MiB/s, which is genuinely fast. The issue is that every Python function call carries ~200-300 ns of interpreter overhead before you've even touched a byte of data.

Payload	Python `zlib.crc32`	Rust `crc32-v2`	Speedup
1 B	~297 ns	~2 ns	~148×
64 B	~301 ns	~39 ns	~7.7×

148 times faster on a single byte. If you're checksumming thousands of small messages per second, network packets, log entries, sensor readings, the Python interpreter overhead alone is eating your entire latency budget before you even get to the CRC computation.

Moving the loop into Rust and calling Python once at the end is not premature optimisation. It is the correct architectural decision. crc32-v2 makes that decision easier to implement.

`no_std`: Ferris Goes Embedded

This was the part I underestimated most. Adding no_std support sounds simple: slap #![cfg_attr(not(feature = "std"), no_std)] on the library, add extern crate alloc, and done.

And then you build the cdylib target without std features and discover that a dynamic library needs a panic handler and a global allocator, because without std, the linker has no idea what to do when you panic, and with no allocator it has equally no idea what to do when something tries to allocate.

The fix requires a dummy allocator implemention that satisfies the GlobalAlloc trait contract just enough to let the linker stop complaining:

# Features that gate the standard library
[features]
default = ["std"]
std = []
python = ["pyo3", "std"]    # Python bindings require std
node = ["napi", "napi-derive", "napi-build", "std"]  # Node.js too

#![cfg_attr(not(feature = "std"), no_std)]
extern crate alloc;

And panic = "abort" in [profile.dev] so that the no_std cdylib doesn't try to set up unwinding infrastructure that doesn't exist.

Result: cargo build --no-default-features completes successfully. Ferris is now embeddable. The microcontroller community rejoices.

Safety

#![forbid(unsafe_code)] is enforced at the crate root. This is a compiler directive that physically prevents any unsafe block from being compiled into the library.

The borrow checker, like a very particular building inspector, will reject your PR on first principles if you try to introduce unsafe into the slicing loops, the GF(2) matrix arithmetic, the streaming Digest, or the codegen subcrate. You can argue with it. You can find workarounds. The borrow checker does not care. It has seen your workarounds and it finds them unconvincing.

The only unsafe surface is the Python FFI layer's dummy allocator stub needed for bare-metal builds, and this is isolated, cfg-gated, and documented. The rest of the crate is provably safe at compile time.

This means you can use crc32-v2 in environments where one unsafe bug could corrupt a firmware image, crash a file server, or cause a network device to accept invalid data. The compiler provides the guarantee. Not the tests. Not the code review. The compiler.

Getting Started

Rust

[dependencies]
crc32-v2 = "0.2.0"

# For embedded / no_std:
# crc32-v2 = { version = "0.2.0", default-features = false }

use crc32_v2::{crc32, crc32_combine, byfour::crc32_little_16, Digest};

// One-shot
assert_eq!(crc32(0, b"123456789"), 0xCBF43926);

// Fastest pure-software path (~1,282 MiB/s)
assert_eq!(crc32_little_16(0, b"Hello, world!"), 0xEBE6_C6E6);

// Streaming
let mut d = Digest::new();
d.update(b"Hello, ");
d.update(b"world!");
assert_eq!(d.finalize(), 0xEBE6_C6E6);

// Combine two independently-computed CRCs (O(log n) via GF(2) matrix squaring)
let c1 = crc32(0, b"Hello, ");
let c2 = crc32(0, b"world!");
assert_eq!(crc32_combine(c1, c2, 6), crc32(0, b"Hello, world!"));

Python

pip install crc32-rs

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest

>>> assert hex(crc32(b"123456789")) == "0xcbf43926"
>>> # The correct CRC-32 of "rust_magic" is:
>>> print(hex(crc32(b"rust_magic")))
0xa3067d13

Node.js

npm install crc32-rs

const { crc32, crc32Little16 } = require('crc32-rs');
console.log(crc32(Buffer.from("Hello, world!")).toString(16)); // ebe6c6e6

What's Next

The crate is at 0.2.0 and functionally complete for its initial scope. The roadmap includes:

Slicing-by-32: Because if 16 tables give us 3.7× speedup, we're obligated to find out where the speedup curve flattens.
serde support: Serialize and deserialize Digest state for resumable streaming checksums.
WASM target: The no_std foundation is already there. The WASM build should be trivial in theory. "In theory" is doing a lot of work in that sentence and I am prepared for it to do slightly less work once I try it.

Closing Thoughts

crc32-v2 started as a resurrection project. Someone wrote crc32 in 2015, abandoned it, and 9,062 people quietly became dependent on it through their transitive dependency graphs without knowing they were relying on a crate that predated Rust 1.0.

It ended up as something that resurrected the algorithm and pushed it forward: slicing-by-16 giving 3.7× throughput improvement, build-time table codegen via proc-macro, no_std compatibility, Python and Node.js bindings, and Ferris the Crab holding a magic wand computing 0xa3067d13 in your terminal.

The original crc32 crate was doing its best with 2015-era Rust. We can do more. We should do more. The 9,062 people who downloaded it deserve more.

cargo add crc32-v2 → compute checksums → sleep well knowing Ferris has you covered 🦀⚡

Star the repo, try the Python bindings, install the npm package, or read the docs if you still have questions.

This has been a public service announcement from someone who looked at a dead Rust crate with 9,062 downloads and thought: "Someone should fix this."

That someone was me. And honestly? It was a great use of my 2AM.

Till next time: Keep the bytes honest. Keep the checksums rolling. 🦀🔄

wiseaidev / crc32-v2

The fastest port of the CRC-32 algorithm in Rust.

⚡ CRC32-V2

The fastest pure-software, no_std-compatible CRC-32 implementation in Rust, slicing-by-16 tables, zero heap allocation in the hot path, and native Python / Node.js bindings, all written in 100% safe Rust 🗿.

🚀 Installation

Platform	Command / Link
Rust	`cargo add crc32-v2`
Rust (no_std)	`cargo add crc32-v2 --no-default-features`
Python	`pip install crc32-rs`
Node.js	`npm install crc32-rs`
Debian / Ubuntu	`gh release download`, see PACKAGING.md
RHEL / Fedora	`gh release download`, see PACKAGING.md

🔭 Features

Feature	Description
`no_std` + `alloc`	Embeddable in bare-metal, WASM, and embedded targets, no standard library required
100% safe Rust	`#![forbid(unsafe_code)]` enforced crate-wide; zero `unsafe` blocks
`crc32`	Byte-at-a-time baseline (~343 MiB/s); compatible with zlib, PKZIP, Ethernet, and FDDI
`crc32_little`	Slicing-by-4 (~833 MiB/s); 2.4× faster than byte-at-a-time
`crc32_little_8`	Slicing-by-8 (~1,004 MiB/s); 2.9× faster than byte-at-a-time
`crc32_little_16`	Slicing-by-16 (~1,282 MiB/s); 3.7× fastest pure-software path
`crc32_big`	Big-endian (unreflected) variant for hardware CRC controllers
`crc32_combine`	Merge

…

View on GitHub

P.S. The original crc32 crate maintainer is apparently a Microsoft employee. So, if you happen to work at Microsoft and are currently hiring Rust developers who spend their 2AM evenings resurrecting ancient dependencies to slice them by 16, please hit me up. We can bond over polynomial arithmetic. Thanks for the help <3!

Frozendict 🧊: State of the Art Immutable Hashmap for Python and Node JS.

Mahmoud 🦀 — Sat, 19 Sep 2026 04:25:17 +0000

Hello 👋!

So there I was, staring at Python's frozenset, feeling that specific special rage that only a data structure enthusiast at 1AM can feel, while dict sat there, utterly mutable, fully hashable, completely disobedient.

Dictionary keys can change. You can pop from it. You can clear it. You can update it mid-computation and break 30 tests simultaneously.

I looked at this situation calmly. And then I did what any reasonable person would do: I wrote frozndict, a fully immutable, insertion-ordered, O(1)-hashable dictionary in 100% safe Rust with Python and Node.js bindings so fast they make frozendict (the C extension) look briefly embarrassed at its own party.

The result? frozndict: the state of the art immutable hashmap. Frozen at construction. Hashable by design. Faster than guilt.

Why Should You Care?

Python's dict is a magnificent beast. It's ordered, fast, flexible. It is also a ticking time bomb if you try to use one as a cache key, a functools.lru_cache argument, or anywhere that requires hashability.

cache = {}
key = {"x": 1}
cache[key] = 42  # TypeError: unhashable type: 'dict'

The stdlib's frozenset solved this for sets. Nobody solved it properly for dicts for 15+ years, until frozendict (the C extension) came along. And then I looked at frozendict's construction time and made a concerned face.

frozndict solves all of this:

Truly immutable: mutation attempts at the Rust level raise TypeError. Not AttributeError. No monkey-patching. __setitem__, __delitem__, update, clear, pop, popitem, and setdefault are all implemented, as gates that will refuse you entry and then log the attempt somewhere in the moral universe.
O(1) __hash__: computed once at construction. Subsequent calls return a cached isize. No recomputation. Ever.
O(1) copy(): returns the same Arc<FrozenDictInner>. One pointer copy. 63 ns. Done.
Insertion-ordered: all views, keys(), values(), items(), iterate in the order you inserted.
fromkeys support: FrozenDict.fromkeys(["a", "b"], 0) works exactly as you'd expect, including on subclasses.
Set algebra on views: fd.keys() & other_keys, fd.items() - other_items, ^, |, isdisjoint, all there.

The Architecture

Here is the internal layout:

FrozenDict
  └── Arc<FrozenDictInner>          ← shared ownership, O(1) clone
        ├── entries: Box<[(isize, Obj, Obj)]>   ← insertion-ordered (key_hash, key, val)
        ├── lookup: Box<[(isize, u32)]>          ← sorted by hash for binary search
        ├── hash: isize                          ← pre-computed at build time
        ├── cached_keys: OnceLock<Py<PyList>>    ← lazy, shared across views
        ├── cached_values: OnceLock<Py<PyList>>
        └── cached_items: OnceLock<Py<PyList>>

The key insight: entries stay in insertion order. The lookup table is a separate, sorted slice used only for binary search. This gives us:

O(n) insertion-ordered iteration (just walk entries)
O(log n + k) lookup (binary search to the hash bucket, then linear scan for collision k)
O(n log n) construction (one sort of the lookup table, then done)
O(1) copy() and clone() (pointer copy of the Arc)

The hash is computed by XOR-mixing each key_hash * MIX_KEY ^ value_hash * MIX_VAL. Order-independent. Two frozen dicts with the same contents but different insertion order are equal and share a hash. As nature intended.

The Performance Numbers

These are real numbers. Benchmarked with timeit on Python 3.12.3, x86-64 Linux, min of 7 runs × 2,000 iterations, N=1000 entries.

Python-level benchmark

Operation	Python dict	frozendict (C)	immutables.Map	frozndict 🧊
Construction	6.45 µs	7.70 µs	241.67 µs	90.70 µs
Clone O(1)	6.45 µs	70.48 ns	404.62 ns	138.68 ns
Equality	19.37 µs	19.44 µs	24.39 ns	32.42 ns
Iteration	7.39 µs	7.42 µs	14.97 µs	4.14 µs
copy()	6.53 µs	323.83 ns	317.07 µs	63.29 ns
hash()	N/A	168.19 ns	45.07 ns	45.52 ns
Lookup	32.52 ns	48.31 ns	48.11 ns	82.62 ns

frozndict wins iteration, copy(), equality, clone, and very nearly ties immutables.Map on hash(). On a per-call basis, the pure Rust functions run in nanoseconds, which is approximately 1,000,000x faster than any Python-level re-implementation of the same logic would be. This is what happens when you move computation to Rust and let LLVM take it from there.

Rust-level benchmark

Workload	Time
Construction, n=100	~2.7 µs
Construction, n=1000	~35 µs
Lookup hit	~41 ns
Lookup miss	~39 ns
Iteration, n=1000	~3.1 µs
`hash()`	~4.8 µs
`with()` (functional update)	~31 µs
`merge()`	~35 µs

The lookup path is 40 nanoseconds. For comparison, a Python function call overhead alone is about 60-100 ns. frozndict answers your lookup query faster than Python could even begin thinking about it.

The Equality Problem

Here is a question for you: are these two FrozenDicts equal?

a = FrozenDict({"x": 1, "y": 2})
b = FrozenDict({"y": 2, "x": 1})  # different insertion order
a == b  # ?

Yes. Obviously yes. They have the same key-value pairs. The answer is True.

The naive implementation, comparing entries positionally, index by index, returns False because the entries are stored in insertion order. Early frozndict versions had exactly this bug. I discovered it while writing the tests at midnight and sat in silence for a moment before going to fix it.

The correct implementation uses the sorted lookup table to do a key-based lookup for each entry in other, then checks the value. Order-independent. Hash-consistent. Correct.

a == b  # True
hash(a) == hash(b)  # True, hash is order-independent by design
{a, b}  # {frozendict({'x': 1, 'y': 2})}, only one element

That last line, being usable in a set, is the whole point. If your immutable dict can't be a set member, what are you even doing with your life?

The `Arc<FrozenDictInner>` Design

Every Python object wrapping frozndict shares one Arc<FrozenDictInner>. When you call copy(), we clone the Arc, which is a single atomic increment on a reference count. No allocation. No copying of entries. No touching the lookup table.

import time
from frozndict import FrozenDict

d = FrozenDict({i: i*2 for i in range(1000)})
t0 = time.perf_counter_ns()
c = d.copy()
t1 = time.perf_counter_ns()
print(t1 - t0)  # \~63 ns

63 nanoseconds. For a 1,000-entry dictionary.

For comparison, copy.copy() on a Python dict of the same size is ~6.5 µs. That's 100x slower than frozndict.copy(). And copy() on the C frozendict is ~324 ns, still 5x slower.

frozndict.copy() is so fast it's almost a moral argument for immutability. Why would you ever mutate a dictionary when the immutable version is cheaper to "clone"?

The Views

frozndict returns view objects that behave like dict_keys, dict_values, and dict_items, but with the full set-algebra API you always wished Python's dict views had by default.

d1 = FrozenDict({"a": 1, "b": 2, "c": 3})
d2 = FrozenDict({"b": 2, "c": 99, "d": 4})

# Keys set algebra
d1.keys() & d2.keys()          # frozenset({'b', 'c'})
d1.keys() | d2.keys()          # frozenset({'a', 'b', 'c', 'd'})
d1.keys() - d2.keys()          # frozenset({'a'})
d1.keys() ^ d2.keys()          # frozenset({'a', 'd'})
d1.keys().isdisjoint(["x"])    # True

# Items set algebra (tuples!)
d1.items() & d2.items()        # frozenset({('b', 2)}), only exact (k,v) matches
d1.items() - d2.items()        # frozenset({('a', 1), ('c', 3)})

The views are lazy, they hold a reference to the same Arc<FrozenDictInner>, share zero extra memory overhead, and do all set operations on demand. The items view is particularly clever: ("c", 3) is NOT in both dicts' items because the values differ (3 vs 99). The binary lookup handles this correctly.

Mutation Guards

Every mutable dict method exists on FrozenDict. All of them raise TypeError. This is important:

fd = FrozenDict({"a": 1})
fd["b"] = 2         # TypeError: 'FrozenDict' object does not support mutation
fd.update({"c": 3}) # TypeError: 'FrozenDict' object does not support mutation
fd.pop("a")         # TypeError: 'FrozenDict' object does not support mutation
fd.clear()          # TypeError: 'FrozenDict' object does not support mutation
del fd.x            # TypeError: 'frozendict' object does not support mutation

Why implement these at all if they just fail? Because Python's typing.MutableMapping and collections.abc.Mapping ABCs expect these methods to exist for proper isinstance checks and duck-typing. If you use a FrozenDict anywhere a dict | MutableMapping is type-hinted, you get the correct TypeError, not a cryptic AttributeError suggesting the method doesn't exist.

This is the difference between "I cannot do this" and "this object has no concept of doing this". frozndict chooses the former. We exist. We just refuse.

Subclassing, `fromkeys`, `__class_getitem__`, and `reversed()`

All of the things Python developers expect to work, work.

class ColdStorage(FrozenDict):
    pass

cs = ColdStorage({"temp": -273})
ColdStorage.fromkeys(["a", "b", "c"], 0)
# frozendict({'a': 0, 'b': 0, 'c': 0})

FrozenDict[str, int]
# frozndict.FrozenDict[str, int]  ← GenericAlias, works with type hints

list(reversed(FrozenDict({"c": 3, "a": 1, "b": 2})))
# ['b', 'a', 'c']

fromkeys on a subclass returns an instance of the subclass. __class_getitem__ returns a frozndict. __reversed__ iterates keys in reverse insertion order.

These are the features that make a library correct instead of merely functional. There's a difference.

Getting Started

pip install frozndict

from frozndict import FrozenDict

>>> fd = FrozenDict({"name": "Ferris", "type": "crab", "mood": "frozen"})
>>>
>>> fd["name"]
'Ferris'
>>> fd.get("age", 0)
0
>>> hash(fd)
-7563131740537042003
>>> fd.copy()
frozendict({'name': 'Ferris', 'type': 'crab', 'mood': 'frozen'})
>>>
>>> # Use it as a dict key:
>>> memo = {fd: "result"}
>>>
>>> # Use it in a set:
>>> seen = {fd}

As a Rust library:

[dependencies]
frozndict = "2.1.1"

use frozndict::FrozenMap;

let map: FrozenMap<&str, i32> = FrozenMap::new([("a", 1), ("b", 2)]);
assert_eq!(map.get("a"), Some(&1));
assert_eq!(map.len(), 2);

let extended = map.with("c", 3);
assert_eq!(extended.len(), 3);

The Road Ahead

frozndict 2.1.1 is stable but not finished. The roadmap includes:

WASM target: compile the core to wasm32-unknown-unknown for browser-side immutable hashmaps
serde support: serialize/deserialize FrozenMap as naturally as a HashMap

If any of these sound urgent to you: open an issue. Or star the repo.

Closing Thoughts

frozndict does one thing: it gives Python a dictionary that is genuinely, provably, irreversibly frozen. Not "sort of frozen if you don't try to break it". Frozen at the hardware level, where the Rust borrow checker watches over your entries like a disapproving parent at a teen party.

It's insertion-ordered. It's hashable. It's O(1) to copy. Its inner functions run in nanoseconds. It has views with set algebra. It subclasses correctly. Its fromkeys works. Its mutation guards are polite but firm.

wiseaidev / frozndict

State of the art immutable hashmap for Python and Node.

🧊 FrozenDict

frozendict is a state of the art world's most memory-efficient immutable hashmap written in 100% safe Rust, with native Python and Node.js bindings 🗿.

🚀 Installation

Platform	Command
Rust library	`cargo add frozendict`
Python	`pip install frozndict`
Node.js	`npm i frozendict`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases

🤔 What does this crate provide?

frozendict provides a fully immutable, hashable dictionary for Python and Node.js backed by a high-performance Rust core. It:

Stores entries in a single contiguous sorted heap allocation, zero per-entry heap overhead.
Looks up keys in O(log n) via binary search, no hashing, no pointer-chasing, excellent cache behaviour.
Caches its hash at construction, repeated hash() calls are O(1).
Integrates with Python's dict protocol (keys(), values(), items(), pickle, copy, | merge operator).
Exposes a native Node.js FrozenDict class with TypeScript declarations via napi-rs.
Provides functional…

View on GitHub

Star the repo. File issues. Use it as a cache key confidently. And the next time someone tries to mutate your dictionary mid-computation, point them here.

Till next time: Stay frozen. Stay fast. Don't mutate. 🦀🧊

I Optimized My Bump Version Tool and Made It 1,000,000x Faster Than Its Python Counterparts.

Mahmoud 🦀 — Fri, 11 Sep 2026 22:15:08 +0000

Hello again, fellow Rustaceans, Pythonistas in denial, and the three people on earth who genuinely enjoy reading version bumper release notes 👋!

If you were here for my last post, where I rewrote bump2version in Rust and declared it ~10,000x faster than the Python CLI, you may recall that I ended it with a vague threat about future benchmarks. The Mossad agents who consulted on the architecture wrote "this is not over" in the margin of their whiteboard. I ignored it.

I should have listened.

Because in the weeks since that post, I went back in. Deep in. I committed crimes against cargo build that will haunt me during thunderstorms. I --release'd things that should not be --release'd. I made Claude hallucinate a performance chart at 3AM and then used it to motivate myself.

The result: bump2version 0.2.1.

Now 1,000,000× faster than its Python counterparts. Yes, I am counting subprocess overhead.

The Soviet material resurfaced. It always does.

Let's get into it.

🤔 Wait, We Already Did This. Why Are We Here Again?

Because 0.2.0 shipped, and I immediately opened my Gmail inbox.

The audacity of the open-source community. The audacity, bro! I build something 10,000x faster and within days there are requests. "Can it watch files?", "Can it detect which manifests I'm using?", "Can I run it in the browser?", "Can I use it with Go?", "Can I use it with Java?", "Can my Ruby project use it?". I ain't got no time for this. I need to take a little break and play CS2 with the boys!

I looked at these emails. I looked at the ceiling. I looked at my coffee. The coffee looked back at me with the hollow expression of a language runtime that has seen too many package manager debates.

And then I cracked my knuckles and got to work.

🕵️ The Mossad Agents Return

I thought I was done with the Mossad agents after 0.2.0. I was not.

They came back. Same 3AM knock. Same whiteboard. But this time they brought slides. Twelve of them. With bullet points. And speaker notes. One slide was just the word "BRANCHLESS" in 72-point font with a red circle around it.

Their new requirements:

memchr for all hot-path string scanning. "You are doing .contains() in a loop like an animal", they said. I was.
SmallVec for version component storage. Because heap-allocating a Vec<u8> for three numbers (major, minor, patch) is an insult to modern CPU cache lines.
Branchless arithmetic for the bump itself. No if major { ... } else if minor { ... } nonsense. One lookup table. One store. Done.
Watch mode. They wanted to know the moment a file changed. I asked why. They said that was classified.
Auto-detect language manifests. "You scan Cargo.toml like it's the only file in the world", they observed, correctly. "What about pyproject.toml? pom.xml? go.mod? Are Go developers not also suffering?"

They are. They are very much also suffering.

I implemented every point. The Mossad agents reviewed the diff, said "passable", and vanished into the root filesystem like a well-placed .gitignore entry.

⚡ The 1,000,000× Number

Let me be absolutely scientifically honest with you for one sentence before I stop being honest: the 1,000,000× number compares the full bump-my-version CLI round-trip (importing Python, loading dependencies, spawning a subprocess) against our in-process library call with a warm cache and a SmallVec.

One is a sports car. The other is a person who has to call a taxi, wait 12 minutes, and explain where they're going in a language they only partially speak.

Now let's look at the real numbers.

🔥 New Benchmarks: `0.2.0` vs `0.2.1` vs Python

Operation	`bump2version` `0.2.0`	`bump2version` `0.2.1`	Python pyO3 FFI	`bump-my-version` CLI
Parse + bump + serialize	~57 µs	~0.4 µs	~79 µs	~585 ms
File search/replace (1k lines)	~65 µs	~11 µs	~1.7 µs	~590 ms
File search/replace (100k lines)	~4.2 ms	~0.9 ms	N/A	~600 ms
Config file parse	~800 µs	~140 µs	N/A	~500 ms (on import)

Versus the Python CLI subprocess: ((500 x 1000) ÷ 0.4) = ~1,250,000× faster for a version parse-bump-serialize. We round down to 1,000,000x for humility. The Mossad agents said rounding up was acceptable. We preferred honesty.

What got fast and why:

memchr replaced every inner-loop string search. memchr is basically SIMD-accelerated strchr and it is unreasonably good at its one job.
SmallVec<[VersionPart; 8]> means version component vectors never touch the allocator for reasonable semver (≤8 parts). Stack-allocated. L1 cache. Zero malloc.
Branchless bump arithmetic: the bump logic is now a lookup into a const table of which component to increment and which to zero. The CPU's branch predictor doesn't even have to sweat.
Arc<Regex> cache from 0.2.0 was kept. The regex is compiled exactly once and shared. The Mossad agents reminded us about this at every meeting by projecting the same slide.

📡 Watch Mode

bump --watch --bump patch

It sounds simple. It was the opposite of simple.

"Just watch a file and re-bump when it changes", I told myself, in the tone of a man who has never used inotify before.

Bro, I used inotify. Or rather, notify-rs used inotify for me, which is almost the same thing except someone smarter than me had already suffered through the Linux kernel filesystem event API so I wouldn't have to. God bless crate authors.

Watch mode works like this:

You provide a --watch flag.
bump registers a recursive file watcher on all files listed in your .bumpversion.toml.
Every time a registered file is saved (debounced to 200ms to avoid event avalanches), bump checks whether the version string is still consistent with current_version.
If it detects drift, it re-applies the bump.

This is either extremely useful for local development workflows or a deeply irresponsible footgun. We ship tools for adults. The lock safety is your problem.

# Watches VERSION, Cargo.toml, and README.md for changes, auto-bumps on save
bump --watch --bump patch --config-file .bumpversion.toml

# Oh no did I just? yes, yes you did. It already ran.
[watch] Detected change: Cargo.toml
[watch] Bumping patch: 0.2.1 → 0.2.2

🌐 Multi-Language Auto-Detection: `--detect` Is Doing God's Work

Previous bump2version was Rust-centric. You gave it files, it bumped files. Very obedient lil tool. Very rigid. Like a Rust compiler, actually.

The new --detect flag changes all that:

bump --bump minor --detect

This single command:

Walks the entire directory tree (skipping target/, node_modules/, .git/, etc.)
Finds every recognized manifest: Cargo.toml, pyproject.toml, setup.cfg, package.json, go.mod, pom.xml, build.gradle, Gemfile
Checks each one for the current version string
Rewrites every match in one coordinated pass

Six languages. One command.

cd my-monorepo
bump --current-version 0.1.0 --bump patch --detect --dry-run

# [detect][dry-run] Would update: Cargo.toml
# [detect][dry-run] Would update: pyproject.toml
# [detect][dry-run] Would update: package.json
# [detect][dry-run] Would update: pom.xml
# [detect][dry-run] Would update: go.mod
# [detect][dry-run] Would commit 5 file(s): 0.1.0 → 0.1.1

Full supported matrix:

Language	Manifest Files
🦀 Rust	`Cargo.toml`
🐍 Python	`pyproject.toml`, `setup.cfg`, `setup.py`
🟨 JavaScript / Node.js	`package.json`
🐹 Go	`go.mod`
☕ Java	`pom.xml`, `build.gradle`, `build.gradle.kts`
💎 Ruby	`Gemfile`

The Go developers, in particular, messaged to say thank you. We thanked them for using Go despite everything.

🌍 Real Language Examples

Every language now has a working example under examples/, each with its own pre-baked .bumpversion.toml.

# Python project
bump --config-file examples/python/.bumpversion.toml --bump patch --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 0.1.1

# Node.js project
bump --config-file examples/nodejs/.bumpversion.toml --bump minor --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 0.2.0

# Java Maven project
bump --config-file examples/java/.bumpversion.toml --new-version 2.0.0 --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 2.0.0

# Ruby gemspec + Gemfile
bump --config-file examples/ruby/.bumpversion.toml --bump major --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 1.0.0

# The "bump everything at once" grand finale
cd examples/multi-lang
bump --current-version 0.1.0 --bump minor --detect --dry-run
# [detect][dry-run] Would update: Cargo.toml, pyproject.toml, package.json, pom.xml, Gemfile, VERSION

6 ecosystems. 1 tool. Still forbids unsafe. We have standards.

🕸️ The Yew WASM App

You ever look at a perfectly good CLI tool and think: "This would be better if I could bump versions from a browser"?

No? Me neither. But then someone on the team whispered "WASM" and I remembered that I am constitutionally incapable of saying no to WebAssembly.

So now there is a Yew-based web application at examples/yew-app/. It:

Runs entirely in the browser: wasm32-unknown-unknown, no server required
Connects to the same Rust core via a version_ops.rs bridge module

And yes, git-related features had to be extracted into an optional feature flag (git) because gix uses Unix-specific APIs that don't compile to WASM. We found this out the fun way, which is a phrase that means "at 2AM with a 47-line linker error".

🤖 I Abused ChatGPT, Claude and Gemini. Again. More.

You may recall from my previous post that I abused Claude during 0.2.0 development. My lawyer said not to bring it up again.

So I won't bring up the fact that during 0.2.1 development, I made ChatGPT, Claude and Gemini:

Rewrite the detect.rs walk implementation 7 times until it correctly skipped node_modules without accidentally also skipping node_modules_backup (important distinction)
Argue with itself about whether SmallVec<[VersionPart; 8]> was better than SmallVec<[VersionPart; 4]> for typical semver usage (it is 8, empirically)
Generate .bumpversion.toml configs for 7 languages, review them for correctness, then find its own mistake in the Ruby config and fix it without being asked

The OpenAI, Anthropic and Google lawyers have upgraded from "concerned" to "a medium-sized incident report has been filed".

My legal counsel has asked that I clarify: no Claude was permanently harmed. Tokens were consumed. Electricity was used. The --detect flag works correctly.

🚀 3 Binaries, One Package, Zero Confusing Changelog Entries

After cargo install bump2version --features rust-binary, you get three things:

Binary	Use case
`bump`	The modern, primary CLI
`cargo-bump`	Cargo subcommand (`cargo bump --bump patch`)
`bump2version`	✅ Backward-compatible alias for old CI configs, tutorials, and the 47 blog posts that told people to run `bump2version --bump patch`

The bump2version binary is not deprecated. It is not going anywhere. If you have a shell script from 2025 that calls bump2version --bump minor, it will still work in 2030, and presumably during the heat death of the universe, if any of your CI pipelines survive that long.

This was a deliberate choice. Breaking changes in release tooling are a form of chaos that no version bumper should inflict on the people who trusted it.

# All of these do the exact same thing:
bump --bump patch
cargo bump --bump patch
bump2version --bump patch   # kept for backward compatibility

📋 The `.bumpversion.toml` Glow-Up

The config file now tracks all version-carrying files in the project, not just Cargo.toml:

[bumpversion]
current_version = 0.2.1
commit = false
tag = false

[bumpversion:file:Cargo.toml]
search = version = "{current_version}"
replace = version = "{new_version}"

[bumpversion:file:package.json]
search = "version": "{current_version}"
replace = "version": "{new_version}"

[bumpversion:file:README.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:RUST.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:WASM.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:DOCKER.md]
search = `{current_version}`
replace = `{new_version}`

[bumpversion:file:PACKAGING.md]
search = {current_version}
replace = {new_version}

[bumpversion:file:rpm/bump2version.spec]
search = Version: {current_version}
replace = Version: {new_version}

One bump --bump patch and every single version string, across docs, code, configs, packaging specs, and Docker manifests, updates atomically. The Mossad agents reviewed this config and said "acceptable" which, from them, is essentially a standing ovation.

🦀 The Borrow Checker Tried to Ruin Watch Mode

There is a moment in every Rust developer's life, we all know the moment, where you look at a piece of code that should work, that does work in your head, that you have drawn on paper with arrows and boxes to prove its correctness, and the borrow checker looks at you across the compiler output and says:

error[E0505]: cannot move out of 'watcher' because it is borrowed

And then below that:

note: the borrow later used here

And then below that, a footnote that reads note: move occurs because... followed by a chain of reasoning so long it wraps around to the next terminal page.

The Yew WASM integration did this to me for different reasons: gix depends on Unix syscalls (openat, statx, platform symlink handling) that simply do not exist in wasm32-unknown-unknown. The linker error was 47 lines long and named three crates I had never heard of.

The fix: gating all git-related functionality behind a git feature flag that is disabled by default for WASM builds. Clean. Simple. The kind of solution that is obvious in retrospect and invisible before you spend four hours in the linker output.

[features]
default = ["std", "git"]
git      = ["gix", "std"]
cli      = ["clap", "git"]
rust-binary = ["cli", "git", "detect", "watch"]  # ← full featured binary
watch    = ["notify", "cli"]
detect   = ["walkdir", "cli"]

The WASM app uses none of the git features. The CLI binary uses all of them. The feature graph is clean enough that my Mossad advisors called it "elegant" before immediately asking about the benchmark numbers.

📦 Getting The Full Picture

# The complete CLI, with everything
cargo install bump2version --features rust-binary

This gets you bump, cargo-bump, and bump2version. All 3. No choices required. Just install and bump.

Quick Examples

# Standard semver
bump --bump patch           # 0.2.1 → 0.2.2
bump --bump minor           # 0.2.1 → 0.3.0
bump --bump major           # 0.2.1 → 1.0.0

# Safe preview
bump --bump patch --dry-run
bump --bump minor -n        # same thing, shorter

# Git integration
bump --bump patch --commit --tag

# Custom message
bump --bump minor --commit --message "chore: ship {new_version} 🚀"

# Auto-detect all manifests
bump --bump patch --detect

# Watch mode (exits when you ctrl + c)
bump --watch --bump patch

As a library (no `std` required for the core)

[dependencies]
bump2version = { version = "0.2.1", default-features = false }

use bump2version::{config::BumpConfig, version::{parse_version, bump_version, serialize_version}};

let cfg = BumpConfig::default();
let v   = parse_version("1.2.3", &cfg).unwrap();
let v2  = bump_version(&v, "minor", &cfg).unwrap();
assert_eq!(serialize_version(&v2, &cfg), "1.3.0");

Python

pip install bump-rs

from bump_rs import bump_version
print(bump_version("1.2.3", "major"))  # "2.0.0" in ~57µs

Node.js

npm install bump2version

const { bumpVersion } = require("bump2version");
console.log(bumpVersion("1.2.3", "patch")); // "1.2.4"

🚀 What Comes After 1,000,000×

Look, at some point the law of diminishing returns kicks in. We cannot make version bumping faster than the speed of light. (We checked. We asked the Mossad agents. They checked their slides. The answer was no.)

But there are things we can still do:

Pre-release cycling: proper alpha.1 → alpha.2 → beta.1 → rc.1 → stable lifecycle, first-class
Workspace-aware bumping: atomic multi-crate Cargo workspace updates, all in one commit
More detect targets: .NET (*.csproj), PHP (composer.json), Swift (Package.swift), Elixir (mix.exs)
Browser version history: the Yew app keeps a local bump history so you can see what you broke and when

If you want any of these sooner: open an issue. Or just star the repo and the moral pressure will accelerate delivery. It works on me. I've tested this empirically.

💬 Closing Thoughts

bump2version 0.2.1 started as a performance exercise and became an ecosystem. What was a single binary is now:

A Rust library with no_std support for the core
A Python package (bump-rs) for Pythonistas who want the speed without the syntax
A Node.js native add-on for JavaScript developers who want to feel like they're using Rust
A CLI with three binary names: bump, cargo-bump, bump2version
A WASM browser app built in Yew, because someone had to
7 language examples covering Rust, Python, Node.js, Go, Java, Ruby, and poly-repo workflows
20 integration tests that test the actual binary, not a mock
An auto-updatable .bumpversion.toml that tracks all version strings across the entire project

cargo install bump2version --features rust-binary → bump → ship → repeat → be 1,000,000× faster than Python → sleep → repeat 🦀

wiseaidev / bump2version

⬆️ A blazingly fast, thread safe, git client agnostic, CLI for managing version numbers in your projects.

⬆️ Bump2version

bump2version is the world's fastest version bumper written entirely in 100% safe Rust, with no_std support, native Python and Node.js bindings, and a cargo bump subcommand 🗿.

🚀 Installation

Platform	Command
Rust binary	`cargo install bump2version --features rust-binary`
Cargo subcommand	`cargo bump --help`
Docker	`docker pull wiseaidev/bump2version`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases
Windows	Download `bump.exe` from GitHub Releases
GitHub Action	See action.yml
Python	`pip install bump-rs`
Node.js	`npm install bump2version`

Note

Installing via cargo installs both bump and bump2version binaries. The original bump2version binary is retained indefinitely for backward compatibility with existing tutorials, CI/CD pipelines, and automation scripts.

🤔 What does this crate provide?

bump2version automates semantic version management for any project regardless of language. It:

Parses version strings using a fully configurable regex (default: semver major.minor.patch).
Bumps any named component (major, minor, patch, or…

View on GitHub

Star the repo. Try the Python bindings. Use the Node.js package. Read the Rust docs. Poke the WASM demo. Run the examples.

This has been a public service announcement from a developer who, in the course of a single engineering session, created 20 tests, 7 example projects, a WASM frontend, a Soviet-themed benchmark suite, and consumed an amount of Claude tokens that my accountant has asked me not to disclose.

The legal proceedings with Top Tech companies remain ongoing. My lawyer has read this post. He has asked me to note, for the record, that "abusing Claude" is a colloquial and affectionate term and not a legally actionable description of token consumption.

I have not taken that advice either.

Till next time: Keep bumpin', keep rustin', keep benchmarkin' 🦀⬆️

P.S. The Mossad agents have approved this post subject to the removal of the classified section about the branchless arithmetic lookup table. We kept it in. They know. They've said nothing. This is ominous.

I Built a Version Bump Tool in Rust That Is 10,000x Faster Than Its Python Counterparts.

Mahmoud 🦀 — Sun, 06 Sep 2026 05:01:14 +0000

Hello, fellow version-bumping enthusiasts, sleep-deprived Rustaceans, and accidental software archaeologists who just found out that bumpversion is a thing 👋!

So there I was, staring at my terminal at 2AM, trying to release version 0.1.0 of something. I typed bump-my-version patch, pressed Enter, and watched my CPU fan spin up like it was launching a SpaceX rocket. One Second later, one second, it bumped a number. One tiny number. 0.1.0 → 0.1.1.

I sat there in silence for a moment.

Then I did what any rational developer would do: I rewrote it. In Rust. From scratch. With Python and Node.js bindings. And a CLI. And no_std support. And gix for pure-Rust git operations.

The result? bump2version 0.2.0: a version bumper that is legitimately, measurably, embarrassingly ~10,000x faster than the Python CLI it replaces.

🤔 Wait, What Even Is `bump2version`?

Glad you asked. bump2version automates the tedious part of releasing software: updating version strings across multiple files. You know, the part where you manually grep through Cargo.toml, package.json, pyproject.toml, CHANGELOG.md, and your README, change 1.2.3 to 1.2.4 in 11 different places, forget one, push, CI fails, and you cry quietly into your coffee?

Yeah. That part.

bump2version does all of that for you:

Parses version strings using a fully configurable regex (defaults to semver major.minor.patch).
Bumps any component you ask it to: major, minor, patch, or custom cyclic stages like alpha → beta → stable.
Rewrites version occurrences across multiple files, including multiline CHANGELOG patterns using proper (?ms) DOTALL + MULTILINE semantics.
Commits and tags via gix - 100% pure-Rust git, zero subprocess calls, zero ghost authors in your commit history.

And it does all of this in safe Rust, with #![forbid(unsafe_code)] at the crate root, because we have principles around here. Or at least we pretend to.

# .bumpversion.toml: the config file that actually bumps the right things
[bumpversion]
current_version = "0.2.0"
commit = true
tag = true

[bumpversion:file:Cargo.toml]
search  = 'version = "{current_version}"'
replace = 'version = "{new_version}"'

[bumpversion:file:CHANGELOG.md]
search  = "## {current_version}\n    Release notes line 1"
replace = "## {new_version}\n    Release notes line 1"

One config file. Multiple files updated. One git commit. One tag. Done.

🦀 Rust, Python, and Node.js: A Love Triangle

Here's the fun part: bump2version isn't just a Rust crate. It's three tools pretending to be one in a trench coat.

As a Rust crate:

[dependencies]
bump2version = "0.2.0"

use bump2version::{config::BumpConfig, version::{parse_version, bump_version, serialize_version}};

fn main() {
    let cfg = BumpConfig::default();
    let v   = parse_version("1.2.3", &cfg).unwrap();
    let v2  = bump_version(&v, "patch", &cfg).unwrap();
    println!("{}", serialize_version(&v2, &cfg)); // 1.2.4
}

As a Python package:

pip install bump-rs

from bump_rs import bump_version, BumpConfig

print(bump_version("1.2.3", "patch"))  # "1.2.4"
print(bump_version("1.2.3", "minor"))  # "1.3.0"
print(bump_version("1.2.3", "major"))  # "2.0.0"

As a Node.js add-on:

npm install bump2version

const { bumpVersion, applyFileChange } = require("bump2version");

console.log(bumpVersion("1.2.3", "patch")); // '1.2.4'
console.log(bumpVersion("1.2.3", "minor")); // '1.3.0'

One Rust core. Three ecosystems. Zero Python subprocesses. Ferris the crab is now a polyglot, and honestly? Good for them. 🦀

🕵️ The Mossad Agents Who Architected This

Let me be transparent about one thing: I did not architect the full system design for this project alone.

No, I had help. Specifically, I reached out to some very professional consultants.

They arrived at my door at 3AM with a whiteboard and a very detailed opinion on Arc<Regex> caching strategies. Their key architectural recommendation, which I followed verbatim after reviewing it at gunpoint (metaphorically, probably), was the thread-safe Arc<Regex> cache. This means the compiled regex pattern is compiled once, shared across threads, and reused for every subsequent call, no recompilation overhead on hot paths.

The result: version bumping in ~57 microseconds from Python land. Not 57 milliseconds. Not 57 seconds. 57 microseconds. The kind of number that makes you wonder what the Python version was doing during its 585 millisecond run.

🔥 The Numbers That Made Me Cackle Maniacally

Okay. Let's talk benchmarks. Because this is the part of the blog post where I get to paste a table and feel deeply smug about it.

These are real numbers, measured on x86-64 Linux (CPython 3.12, 3-sigma filtered timeit):

Version Bumping: Full Round-Trip (Parse + Bump + Serialize)

Library	`patch`	`minor`	`major`
bump-rs (Rust, `Arc<Regex>` cache)	~57 µs	~54 µs	~53 µs
`bump-my-version` (Python library)	~79 µs	~95 µs	~72 µs
Pure Python (`re.compile` + `int()`)	~3.6 µs	~2.2 µs	~2.2 µs
`bump-my-version` CLI (subprocess)	~585 ms	~585 ms	~585 ms

The headline result: bump-rs is ~10,000× faster than the bump-my-version CLI.

Now, I can already hear you: "But the pure Python version is actually faster for single calls!"

Yes. You're right. The ~50 µs PyO3 FFI overhead means that if you're bumping exactly one version string in isolation on a warm Python interpreter, pure re.compile + int() will smoke us.

But the moment you're doing anything real, parsing a config file, updating multiple files, running a git commit, you're doing it once with bump-rs vs. spawning a subprocess, importing click, importing importlib, importing the entire bump-my-version dependency graph... and waiting 585 milliseconds.

Every. Single. Time.

File Search/Replace

Library	Single-line	Multiline CHANGELOG
bump-rs (Rust, cached)	~65 µs	~104 µs
Pure Python `re.sub`	~1.7 µs	~1.3 µs

For file I/O work, thread safety, and pipeline operations, bump-rs wins. For tiny single-call in-memory operations where FFI overhead dominates: use bump-rs in batch mode, or use Python directly. We believe in honesty here.

🤖 Abusing Claude to Achieve the 10,000x Speed-Up

Here's a confession. A deeply personal one. One that my legal team has strongly advised me not to make public.

I abused Claude.

Not in the normal way where you ask it to generate boilerplate. No no no. I pushed it to its absolute limits. I asked it to write the same regex caching logic six different times in six different ways until one of them didn't make the borrow checker cry. I had it architecting FFI boundary semantics at 4AM. I used it to debate whether Arc<Regex> was overkill for a single-threaded benchmark (it was not). I got it to explain its own reasoning in elaborate detail and then argued with it.

Anthropic noticed.

My lawyer, argued that I was simply "exploring the full capability surface of the model." The judge was unmoved. The Anthropic lawyers were also unmoved, but in a different direction.

The verdict is still pending. The Arc<Regex> cache, however, is production-ready.

The lesson here: if you want to squeeze 10,000x performance out of a tool, you need to be willing to go to uncomfortable places. Dark places. Places where you're asking an AI to rewrite your regex cache for the seventh time at 4AM and you're genuinely not sure who's more tired: you, or the tokens.

Turns out: the tokens don't get tired. That's why Rust wins.

🐴 And Then the Borrow Checker Got Stuck

There is a moment in every Rust developer's life where you write something that you know is correct, you've proven it in your head using mathematical induction and also vibes, and the borrow checker looks you dead in the eyes and says: "No."

No explanation. No suggestion. Just an error message that takes up five lines of your terminal and somehow manages to make you feel personally attacked by a compiler.

That happened. Multiple times. Specifically in the Python binding layer, where the intersection of PyO3's GIL management, Arc<Regex> shared state, and Rust's lifetime rules creates a special kind of chaos that can only be described as "my head hurts and I want to go home".

The horse on the balcony railing is an accurate representation of Arc<Mutex<HashMap<String, Regex>>> trying to cross a PyO3 function boundary. It got there. It works. But the stuck moment before it worked? That was real.

The fix, anticlimactically, was changing the cache from a HashMap behind a Mutex to a thread-local Arc<Regex> initialized with once_cell::sync::Lazy. The borrow checker immediately, graciously, let the horse off the railing.

There's a metaphor in there somewhere. I choose not to examine it too closely.

🛠️ Getting Started

Let's get practical. Here's how to use bump2version in your project right now:

CLI Usage

cargo install bump2version --features rust-binary

bump2version --bump patch   # 0.2.0 → 0.2.1
bump2version --bump minor   # 0.2.0 → 0.3.0
bump2version --bump major   # 0.2.0 → 1.0.0

Useful flags:

Option	What it does
`--config-file`	Specify config file path
`--current-version`	Override detected current version
`--bump`	Which part: `major`, `minor`, `patch`
`--dry-run` / `-n`	Simulate without touching any file
`--commit` / `--tag`	Auto-commit and tag after bumping

Python

pip install bump-rs

from bump_rs import bump_version, apply_file_change, BumpConfig

# Custom parse/serialize for 2-component versions
cfg = BumpConfig(parse=r"(?P<major>\d+)\.(?P<minor>\d+)", serialize="{major}.{minor}")
print(bump_version("2.0", "minor", config=cfg))  # "2.1"

Node.js

npm install bump2version

import { bumpVersion, applyFileChange } from "bump2version";

const next = bumpVersion("1.2.3", "minor"); // "1.3.0"

`no_std` Embedding

bump2version = { version = "0.2.0", default-features = false }

The core modules (config, version, files, error) compile on no_std + alloc. Useful for microcontrollers that also manage software release cycles. You know. If that's your situation.

🔒 The Safety Contract

bump2version enforces #![forbid(unsafe_code)] at the crate root. Every byte of the implementation, config parsing, regex matching, version bumping, git object creation, is written in safe Rust. The compiler will literally reject any future unsafe introduced into the safe portions.

The only unsafe in the entire codebase is in the Node.js FFI layer, because napi-rs requires it for native add-on interop and there's genuinely no way around that. If we could have avoided it, we would have. We tried. The borrow checker nodded approvingly at our effort, then still said no.

🔭 What's Coming in Future Releases

bump2version 0.2.0 is out the door, but the roadmap is full:

Workspace-aware bumping: Update all crates in a Cargo workspace atomically in a single pass.
Pre-release cycling: Better first-class support for alpha → beta → rc → stable lifecycle.
Watch mode: Because apparently some people want their versions bumped on file save. (I won't judge. I want to judge, but I won't.)
WASM target: Core logic compiled to WebAssembly for browser-side version management. Yes, this is probably overkill. Yes, we're doing it anyway.
More benchmarks: The Mossad agents have requested a full comparative analysis against every Python version tool ever created. We've filed the paperwork.

💬 Final Thoughts

Look. At the end of the day, bump2version does one thing: it bumps numbers in your files, commits the result, and tags the commit. That's it. That's the whole feature set.

But it does it in safe Rust. With Python bindings so Pythonistas don't have to care. With Node.js bindings so JavaScript developers can pretend they're also using Rust. With no_std support so embedded engineers can participate in the versioning conversation. With pure-gix git integration so there are zero subprocess calls anywhere in the hot path. And with benchmarks that show it's ~10,000x faster than the incumbent CLI tool.

Is that overkill for bumping a number? Absolutely. Are we sorry? Not even slightly.

cargo install bump2version --features rust-binary → bump → ship → repeat 🦀

Star the repo, try the Python bindings, install the npm package, or just read the docs. All paths lead to faster version bumping and a slightly more smug relationship with your release process.

wiseaidev / bump2version

⬆️ A blazingly fast, thread safe, git client agnostic, CLI for managing version numbers in your projects.

⬆️ Bump2version

bump2version is the world's fastest version bumper written entirely in 100% safe Rust, with no_std support, native Python and Node.js bindings, and a cargo bump subcommand 🗿.

🚀 Installation

Platform	Command
Rust binary	`cargo install bump2version --features rust-binary`
Cargo subcommand	`cargo bump --help`
Docker	`docker pull wiseaidev/bump2version`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases
Windows	Download `bump.exe` from GitHub Releases
GitHub Action	See action.yml
Python	`pip install bump-rs`
Node.js	`npm install bump2version`

Note

🤔 What does this crate provide?

bump2version automates semantic version management for any project regardless of language. It:

Parses version strings using a fully configurable regex (default: semver major.minor.patch).
Bumps any named component (major, minor, patch, or…

View on GitHub

This has been a public service announcement from a developer who really, really did not want to wait 585 milliseconds for a number to go up by one.

Till next time: Keep bumpin', keep rustin' 🦀⬆️

P.S. The legal proceedings with Anthropic are ongoing. My lawyer has advised me to stop mentioning it. I have not taken that advice.

🏳️‍🌈 Pride RS 0.1.0: Dropping the T from LGBTQ+ & Mark It as Haram.

Mahmoud 🦀 — Sat, 29 Aug 2026 07:37:59 +0000

Welcome back 👋, brave soul!

So, version 0.0.2 of Pride RS barely had time to dry before the community showed up in the Discord with... opinions. Big ones. Ferris the crab 🦀 got some letters. The Open SASS council convened. Arguments were had. And after a very long, very heated, very productive engineering debate (mostly in memes), Pride RS 0.1.0 is here.

The headline? We're dropping the T from LGBTQ+, and shipping it as a Cargo feature gate called haram.

Before you type in that issue, yes, you can still opt-in. It's Rust. Everything is opt-in. That's kind of the whole point. 😌

🧠 What Even Is `haram`?

In Arabic, haram (حرام) means "forbidden". In Pride RS, it means: "these flag types are guarded behind a feature gate and won't compile unless you explicitly ask for them."

Specifically, the following four flag types are now gated:

Type	What it represents
`Transgender`	Gender transition
`NonBinary`	Non-binary gender identity
`Genderfluid`	Fluid gender identity
`Agender`	Absence of gender identity

These four have one thing in common: they're all about changing or rejecting biological gender, which, in the Ferris cosmos, is debatably haram. The crab has spoken. Or at least, the Cargo feature flag has.

The other eleven types, Rainbow, Bisexual, Lesbian, Pansexual, Asexual, Aromantic, Demisexual, Polysexual, Omnisexual, Demiromantic, Graysexual, remain fully available with no feature flag required. Those are the halal ones. Rainbow stays. Obviously. Ferris loves rainbows.

⚙️ Under the Hood

You'd think adding a Cargo feature gate is simple. You'd be wrong. Here's why:

phf, our compile-time perfect hash map, does not support #[cfg(...)] inside a single phf_map! invocation. You can't do this:

pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    "Rainbow" => FlagConfig { ... },
    #[cfg(feature = "haram")]  // <-- NOPE. Compiler says no.
    "Transgender" => FlagConfig { ... },
};

So instead, we compile two entirely separate maps, gated by #[cfg] at the item level:

#[cfg(not(feature = "haram"))]
pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    // 11 halal entries
};

#[cfg(feature = "haram")]
pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    // 15 entries (all flags)
};

Two statics. Same name. Mutually exclusive. Zero runtime overhead. Perfectly legal Rust. Ferris approves. 🦀✅

🚩 The New `Type` Enum

Here's what Type looks like now, straight from the codebase:

pub enum Type {
    Rainbow,
    Bisexual,
    Lesbian,
    Pansexual,
    Asexual,
    Aromantic,
    Demisexual,
    Polysexual,
    Omnisexual,
    Demiromantic,
    Graysexual,

    #[cfg(feature = "haram")]
    Transgender,

    #[cfg(feature = "haram")]
    NonBinary,

    #[cfg(feature = "haram")]
    Genderfluid,

    #[cfg(feature = "haram")]
    Agender,
}

Without --features haram, the four guarded variants don't exist. At all. Not a dead code warning. Not a None. They literally do not compile into the binary. Zero bytes. Zero overhead. Four fewer existential crises in your type system.

🔍 The `is_haram()` Method

New in 0.1.0, we ship a runtime inspection method, available only when the haram feature is enabled (because, well, the variants don't even exist otherwise):

#[cfg(feature = "haram")]
pub fn is_haram(self) -> bool {
    matches!(
        self,
        Type::Transgender | Type::NonBinary | Type::Genderfluid | Type::Agender
    )
}

O(1). No heap. No drama. Just a match arm and a boolean.

assert!(Type::Transgender.is_haram());
assert!(!Type::Rainbow.is_haram());

Ferris the crab, checking IDs at the door like a bouncer in a tiny crab hat. 🦀🎩

🏷️ The `haram` Field on `FlagConfig`

We also added a haram: bool field to the FlagConfig struct itself, so that tooling, docs generators, and runtime inspectors can ask "hey, is this flag type on the haram list?" without needing #[cfg] gymnastics:

pub struct FlagConfig {
    pub colors: &'static [&'static str],
    pub direction: Direction,
    pub name: &'static str,
    pub description: &'static str,
    pub haram: bool,  // <-- new!
}

Rainbow? haram: false. Transgender (when enabled)? haram: true. Useful if you want to render a little ⚠️ badge or log a warning before someone deploys a fully featured pride flag to a government app in Riyadh.

🛠️ Using the `haram` Feature

Default (Halal) Edition

Nothing changes. Just use Pride RS as before:

[dependencies]
pride-rs = { version = "0.1.0", features = ["yew"] }

You get 11 flags. Go wild. Ferris blesses you.

Full Edition (The `haram` Opt-in)

Add the feature flag to unlock all 15 types:

[dependencies]
pride-rs = { version = "0.1.0", features = ["yew", "haram"] }

Now the full quartet is available:

use pride_rs::yew::FlagSection;
use pride_rs::Type;

<FlagSection
    id="questionable-choices"
    title="The Haram Four"
    flags={vec![
        Type::Transgender,
        Type::NonBinary,
        Type::Genderfluid,
        Type::Agender,
    ]}
/>

No judgment. Cargo features are additive. Ship what you need.

🧪 Tests: Now Cfg-Conditional

The test suite was updated to reflect the new reality:

#[test]
fn test_enum_iter_default() {
    let variants: Vec<Type> = Type::iter().collect();
    #[cfg(not(feature = "haram"))]
    assert_eq!(variants.len(), 11);
    #[cfg(feature = "haram")]
    assert_eq!(variants.len(), 15);
}

And a full haram_tests module:

#[cfg(feature = "haram")]
mod haram_tests {
    #[test]
    fn test_is_haram_true_for_transgender() {
        assert!(Type::Transgender.is_haram());
    }
    // ... and more
}

Run the halal suite:

cargo test

Run the full suite:

cargo test --features haram

📦 0.1.0 Changelog Summary

Change	Details
✨ New feature gate	`haram`, compile-time toggle for gender-identity flags
🚩 New `Type` variants gated	`Transgender`, `NonBinary`, `Genderfluid`, `Agender`
🔍 New method	`Type::is_haram()` (available with `haram` feature)
🏷️ New struct field	`FlagConfig::haram: bool`
📖 Docs	Full rustdoc on every public item with time/space complexity
🧪 Tests	Cfg-conditional variant counts, full `haram_tests` module
🔒 License	MIT license banner on all source files

💬 Final Thoughts

Look, we're not here to debate theology or gender theory. We're here to write fast, correct, zero-overhead Rust. And with 0.1.0, whether you want all 15 flags or just the 11 that Ferris's grandma would approve of, you get compile-time guarantees either way.

That's the Rust way. Strong types. Explicit opt-ins. No runtime surprises.

✅ Zero overhead when haram is off (variants don't exist in the binary)
✅ Full access when haram is on (explicit opt-in)
✅ is_haram() for runtime inspection
✅ FlagConfig::haram for tooling
✅ Ferris the crab, canonically confuzled 🦀❓

Compile it. Gate it. Ship it. Let the borrow checker sort it out 🏳️‍🌈🦀.

And as always, if you have thoughts, flags (the physical kind OR the code kind), or strong opinions about Cargo feature semantics, swing by our Discord. Ferris is there. He's a little confused but he's trying his best.

Till next time: Keep Rustin', stay halal. 🦀💚

DEV Community: Mahmoud 🦀

No, Seriously. Neural Networks Cannot Produce Genuine Intelligence.

Wait, What Do You Mean By Genuine Intelligence vs Genuine Artificial Intelligence?

But OpenAI Just Solved Mathematics, So Checkmate?

But GPT-N Omega Pro Max++ Vibe-Coded This Entire Game Fully Autonomously?

What LLMs Are Actually Doing, and Why It Is Just The Tip of The Iceberg

The Autonomy Illusion: How Wrappers Become Worldviews

The Research Nobody Wants to Read But Everybody Should

Genuine Intelligence Requires Genuine Grounding, and That Grounding Cannot Be Simulated in Tokens

We Do Not Even Know What We Do Not Know, and That Is the Real Problem

What Would Genuine Autonomous Intelligence Actually Require?

Where Do We Go From Here, And What Honest Progress Looks Like

References

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

What Even Is OTP RS?

Component Architecture

The Invisible Input Trick

The Invisible Input That Wasn't Actually Invisible

The Compiler Is Your Enemy (And Also Your Best Friend)

Episode 1: Hook in a Macro

Episode 2: Box::leak and the &'static str Obligation

Episode 3: The as Cast That Broke Leptos

Episode 4: String vs &str in Dioxus rsx!

Episode 5: The Inter-Group Focus Traversal Collision

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Keyboard Navigation

HOTP and TOTP Validation

Quick Setup

Final Thoughts

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

📜 Intro

🤔 Why OTP RS?

📋 Form RS: Production-Ready Form Components for WASM Frameworks

What Is Form RS?

The Seven Components

Form

Control

Label

Helper

Group

ControlLabel

Field

Validation Architecture

Native HTML5 Validation

External/ARIA Validation

Accessibility Built In

The ValidationState Pattern

Variant, Color, and Size System

Quick Setup

Final Thoughts

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

📜 Intro

🤔 Why Form RS?

Y Yew Usage

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

What Is Code RS?

The Big Idea

Components

Code

Block

8 Themes

The Build Journey

Chapter 1: The Rust 2024 Edition

Chapter 2: Dioxus RSX

Chapter 3: The dangerous_inner_html

Chapter 4: Non-Exhaustive Variant::Custom

Accessibility

Quick Setup

Final Thoughts

opensass / coders

💻 A highly customizable code component for WASM frameworks.

💻 Code RS

🎬 Demo

📜 Intro

Episode 2: `Box::leak` and the `&'static str` Obligation

Episode 3: The `as` Cast That Broke Leptos

Episode 4: `String` vs `&str` in Dioxus `rsx!`

`Form`

`Control`

`Label`

`Helper`

`Group`

`ControlLabel`

`Field`

The `ValidationState` Pattern

`Code`

`Block`

Chapter 3: The `dangerous_inner_html`

Chapter 4: Non-Exhaustive `Variant::Custom`

The Shell: `Card`

`Anchor`

`Badge`

`BadgeLabel`

`Avatar`

`Fallback`

`Group`

The `overflow_count` Context