Rust, C++, and the Creative Power of Free Software

Leandro Rabindranath León — Tue, 02 Jun 2026 21:47:41 +0000

C++, a Mother Tongue

For a large part of my professional life, C++ has been more than a programming language. It has been a mother tongue. Not in the sentimental sense of the word, but in a deeper and more circumstantial one: for years I have thought and implemented data structures, algorithms, distributed systems, abstractions, and efficiency problems in C++. Many times, before writing a single line of code, my imagination was already organized in terms of constructors, destructors, templates, move semantics, pointers, and execution costs.

Although its reputation had already caught my attention, I did not encounter Rust out of enthusiasm or fashion. My work circumstances forced me to learn it. C++ is not, to me, an old language that must be abandoned. I think it is a powerful, intimate, hard tool, full of scars but also victories, with which extraordinary software can still be built. In a sense, C++ gave me a way of thinking. It taught me the closeness between abstraction and the machine, and to respect the cost of every decision. I do not renounce C++: I owe it too much.

That is precisely why my growing admiration for Rust surprises even me. It does not come from ignorance of C++, but from having known it too well. Anyone who has lived for many years inside C++ understands that one of its greatnesses is also one of its tragedies: it has been an immensely capable language, but terribly slow to transform itself. I do not say this with contempt; that slowness has understandable causes, and I will return to them. But, looking at Rust over this last year, I came to understand something about C++ that is not what people usually say, and that I could only formulate when I stopped thinking in terms of a single problem and began to see two.

And I did not learn that distinction by reading theory about programming languages. I learned it by struggling with both languages, between the dangerous freedom of C++ and the irritating severity of Rust.

Invention and Verification: Two Very Different Questions

Every technical culture faces two different questions, and many misunderstandings about standards are born from confusing them into one.

The first question concerns invention: with what freedom, and at what moment in relation to practice, new ideas are allowed to enter. The second concerns verification: with what rigor what has already been written is checked for correctness. These are independent axes. A culture can be bold in one and severe in the other without contradiction; in fact, the most fertile cultures are.

I was educated under the Cartesian doctrine and, although I appreciate that style of thought for the discovery of knowledge, I practice it and I am convinced that doubt is a great friend of truth. From the beginning of my training in research, I came to grasp that practice often precedes theory. Reversing that order is usually dangerous and unproductive; in the best of cases, it slows creativity.

When we look at the long history of technology, we notice that many of the great inventions, perhaps most of them, were not born from a mature scientific theory, but from craft, necessity, trial and error: the airplane, the electric light bulb, the automobile, the steam engine, the first vaccine, penicillin, and plenty of other examples. I do not mean to deny the movement in the other direction: GPS, the transistor, the laser, and so many modern technologies would be inconceivable without prior formal science. But I cannot help being amused by fanatical Cartesians who swear that theory always comes first and practice afterward. No. They remind me of Borges’s story “On Exactitude in Science,” where cartographers end up building a useless map the same size as the kingdom. Or Taleb’s joke about teachers giving flying lessons to birds and, when they see them fly, assuming it was thanks to their lessons.

Perhaps that is why I am convinced that, when inventing, it is healthy to give an idea almost all the air it asks for. An idea may be born imperfect, debatable, half-cooked. Let it roll around, make mistakes, and be polished by daily use. If it works, excellent: then let the norm come and stabilize it. The reverse is pathological. Putting the rule before the practice — letting a committee dictate what exists before anyone has lived it — does not organize creativity. It domesticates it. Or worse: it aborts it.

Practice Before the Norm

In software development this is even more true. I know of no other craft that works with such docile matter. Where other forms of engineering often pay dearly for their tests, the programmer risks almost nothing: undo, redo, test again in seconds; modify on the fly; turn the keyboard into a laboratory that never closes. This dizzying speed is not merely a convenience: it is the very engine of invention, because the cost of being wrong is much lower.

In software, during that dialogue between the idea and the result, what was not foreseen often begins to appear. An intelligent programmer sails through an ocean of epiphany, with serendipity lying in wait, where he does not fully know what he is building until he has built it, and the work, as it takes shape, suggests new paths. Being able to follow those paths in real time is the luxury of this craft: when such paths appear in other kinds of engineering, it is often too late to take them. Here practice does not merely precede theory: sometimes it gives birth to it.

It is worth adding a current concern: it is possible that one of the virtues I attribute to software — its speed of probing, error, and recomposition — may change with the arrival of artificial intelligence. Used well, AI can expand the workshop and accelerate exploration. But, used badly, it introduces a dangerous comfort: it offers a probable answer before one has faced the problem. And facing the problem matters, because that is where judgment is forged; that is where the unforeseen is discovered; that is where, many times, invention appears. If AI spares us that friction, it may end up doing gently what the standard used to do solemnly: establishing a prior form before living experience. Except that now the norm does not descend from a committee; it emerges from statistics and disguises itself as help.

But on the axis of verification, this changes. Here Cartesian rigor is very valuable, and rigor must rule. Good faith in the self-discipline and authority of the creator is not enough for what has been invented to become a public rule. It must be reviewed, verified, and validated: by the compiler, by the team, by whoever must do it. Being strict here is not building walls; it is taking care of the process. An error detected in time is one less disaster in the future.

C++ and Rust do not differ because one has guardians and the other does not: both have them. They differ in which axis each one emphasized more and less: one on the axis of invention, the other on the axis of verification.

C++ was slow on the axis of invention. For years, many ideas that other ecosystems had already naturalized — the best example is the introduction of lambdas and the functional style — arrived late in the language, after long discussions, precautions, and almost always well-intentioned resistance. It is fair to acknowledge, however, that this slowness was not eternal: after C++11, the committee adopted a regular cadence and delivered, one after another, tools that earlier might have taken a decade to appear.

On the axis of verification, C++ is something like “I know what I am doing”; the language and the compiler trust me. An aristocratic wager with its own justifications: backward compatibility, ABI stability, not breaking code, and so on. But that decision, perhaps unconscious, had a double price: on the one hand, the delays that rigor imposed on its invention restricted the language’s creativity (I suspect that anyone who has programmed functionally must detest C++ iterators as much as I do); on the other, permissiveness on the verification axis made the silent catastrophe possible: code defects that often survive intact all the way into production.

Rust made the opposite bet by being permissive in invention — and by remaining so. cargo and crates.io are a permanent community laboratory, where an idea can appear, solve a problem, make mistakes, be replaced, or become a de facto practice, with very little bureaucracy, without waiting for sanctification from above. Its RFCs, when they work well, should not prevent practice from exploring; rather, they provide a mechanism to collect, discuss, and stabilize what experience, use, or technical need have made sufficiently serious. By contrast, in verification, Rust is severe: the borrow checker does not trust the programmer’s private discipline; it makes that discipline public and checkable.

This resolves a paradox that for some time seemed difficult for me to get around. If standards are a border checkpoint for the imagination, is the borrow checker not an implacable police officer? It rejects programs that may be correct, tends to impose a single discipline, and demands permission. The answer appears when we realize that the borrow checker does not live on the axis of invention, but on the axis of verification. It does not decide what ideas may exist; it does not tell me what I may think. It only requires me to demonstrate that what I wrote does not corrupt a model of memory use that I share with others.

Rigor in verification is not the enemy of creative freedom; on the contrary, it may be its complement. What must not happen is that we confuse two guardians of a different kind. While a committee takes ten years to accept a new idea, standing in permanent custody over the new, a compiler that rejects a dangerous pointer in seconds is guarding something else: the integrity of the whole. And not the integrity of the pointer it rejects — that pointer was never built — but of everything that pointer would have put at risk. The first may become a border checkpoint for the imagination. The second, when it does its job well, is a form of collective care.

That is why the formula that matters is not “fewer rules,” nor “more freedom” in the abstract. It is more precise: permissiveness on the axis of invention, rigor on the axis of verification. Cultures that are severe and blocking toward new ideas, yet lax about correctness, do not produce excellence. They produce museums: they age, sometimes with good manners.

The Test of the World

Such paralysis, in this very competitive world, is not necessarily an elegant way to grow old: it can be a sentence. What Schumpeter called creative destruction — a concept I do not need to embrace completely in order to recognize its share of truth — does not forgive slowness. You do not defeat a competitor by obeying existing procedures better; you defeat him by imagining what those procedures do not yet know how to describe.

That is why what impresses me most about Rust is not, ultimately, any isolated technical feature, but the fact that its bet — permissiveness in invention, rigor in verification — ceased to be a laboratory hypothesis and passed the test of the world. In a few years, Rust went from being a promising oddity to becoming a serious, respected, feared language, adopted in domains where almost no one would previously have dared to challenge C or C++. It also achieved something that for a long time seemed contradictory: memory safety without a mandatory garbage collector, modern abstractions with competitive performance, proximity to the hardware without surrendering to the barbarism of the naked pointer.

Its entry into the Linux kernel is, in that sense, symbolically enormous. Not because Linux is going to be rewritten in Rust — that is not seriously on the table — but because the kernel represents one of the most demanding, conservative, and politically difficult territories in systems software. The fact that Rust has reached even that threshold indicates that we are no longer dealing with an academic toy or a passing fashion. And we should not sugarcoat the process: adoption has been slow, conflictive, full of tensions. But that makes it more significant, not less. No language enters the Linux kernel out of aesthetic sympathy. It enters because someone, after much resistance, begins to accept that there is a technical promise there that is hard to ignore.

For me this is a lesson I would not want to be lost: Rust is, before it is an argument, an accomplished fact: it exists, it works, it sustains itself. And an accomplished fact defeats a thousand speculations and proposals. For years one could discuss in the abstract whether safety without a garbage collector was possible, whether it was worth it, whether the world would want it; Rust settled the discussion in the only way such discussions are truly settled: by happening.

Without disdain for the value of standards, which make ordinary what was once extraordinary, which organize what practice has already learned and spare us chaos, clinging to them dogmatically is foolishness that strangles the diversity and creativity from which everything new is born. The new does not ask the committee for permission: it happens first and imposes itself afterward.

Democratizing Without Absolving

Rust does not eliminate the fragility of software; it would be naive to say so. What it does is move an important part of the risk to a more visible and earlier stage: compilation. Many errors that in C++ can survive all the way into production — memory errors, certain data races, improper uses of references, dangerous forms of aliasing — are confronted earlier in Rust, in that sometimes exasperating conversation with the compiler and the borrow checker.

But that does not make every program written in Rust robust, elegant, or efficient. I have seen it several times: safe, correct programs that do their job and yet are mediocre, inefficient, sown with clones and unnecessary detours that reveal someone who has not yet mastered software engineering. They are rarely fixed with a single tweak. Repairing this kind of problem usually requires a deep and expert review. The compiler prevents many errors, but it does not teach us to use the language with good judgment: the borrow checker is satisfied with a clone where skill would have used a simple reference. Safety can be guaranteed; mastery cannot. Rust democratizes more, but it does not absolve.

It is worth being exact, however, about which barrier Rust lowers and which one it does not. It does not lower the barrier of learning: Rust is not a simple language, and whoever claims otherwise, I suspect, has not used it seriously. In some respects, it is as complex as C++, perhaps even more so, although its complexity manifests itself differently. What Rust lowers is the barrier of catastrophe. In C++, avoiding memory disaster depends largely on the silent heroism of the programmer: on his discipline, attention, and infallible memory (which, inexorably, fails with time). In Rust, a large part of that care stops resting on the shoulders of an individual and becomes a verifiable property of the program. That difference does not automatically produce good systems programmers; it does not. But it opens a territory that once seemed reserved for a very small elite and allows more minds into the workshop without first having to survive the harshest apprenticeship of C or C++.

In Rust something emerged that I believe was unexpected: part of computer systems engineering ceased to belong exclusively to an aristocracy. But this also carries a danger: it can engender a technical demagogy similar to the worst political populism. Just as the demagogue flatters people by telling them that their immediate will is already capacity, technical demagogy flatters the programmer by telling him that access to the instrument is enough to master the practice. It is the same deception: confusing access with mastery, the tool with the hand that governs it.

The solution is not to renounce this opening, but to distinguish what the barrier of the aristocracy used to hide. A barrier to entry carries two things from the start: one cruel and arbitrary, which deserves to be abolished, and another real and earned — the craft — which no language can give away. The demagogue deliberately confuses them; the good engineer or technical leader separates them. In this sense, Rust can empower without deceiving by tearing down cruelty without abolishing demand.

There is a name for that opening, and it does not come from politics but from systems thinking: heterarchy, where command, instead of being vertical, is distributed according to competence, context, and capacity. Even in domains as hierarchical as the military, heterarchy has been attempted. In his book Turn the Ship Around!, David Marquet tells how, while commanding a nuclear submarine, he shifted authority toward those who had the information and competence to act, turning a lagging crew into a high-performing one. He did not declare them leaders by decree; he pushed authority toward the place where craft was growing. This is the crucial difference: the demagogue says “now you have power, now you command”; heterarchy says “you may become empowered if you learn how to command.”

Three Planes of the Shared

This opening is not the isolated effect of a fortunate feature. When one looks closely, one discovers that the same choice — placing what is shared ahead of what is individual — is repeated on three different planes of Rust, and that it is there, not in any proclamation, that its character resides.

The first plane is process. What Rust will become is not decided by an authority behind closed doors, but through public deliberation: anyone may propose, with the discussion visible, and the decision emerges, ideally, from the best argument, but above all from the impact of the result, not from the highest rank. The compiler, the library, the tools with which everyone works belong to everyone.

The contrast with C++ is real: C++ is governed by a committee of representatives — compiler vendors, large companies, national bodies, and highly specialized experts — a form closer to a chamber than to an assembly. It is important not to idealize: in Rust, real power is concentrated in a few teams; first Mozilla, and today the sponsors of its foundation, weigh with their own gravity, and the project has had its crises over who truly commands. But the form toward which it tends is participatory.

The second plane is cultural. Rust deliberately chose to welcome the newcomer. The compiler corrects like a teacher, with excellent error messages bordering on mentorship and explicit norms of conduct. Everything is oriented toward mitigating the pain of initiation rites. In a more interesting gesture, Rust took certain ideas from type theory and systems programming that for a long time seemed reserved for specialists, and placed them in the hands of the ordinary programmer. It put within reach of the common person capacities that had been the privilege of an elite. C++, by contrast, cultivated a more aristocratic, often pedantic culture, where difficulty is sometimes worn as a distinction and the filter defended as a virtue.

The third plane is the most surprising, because it lives inside the code, where no one would expect to find a choice beyond the technical. In C++, memory safety is a private virtue: it rests on the sovereign individual who declares, “I know what I am doing.” In Rust, it ceases to be private. It becomes a public, shared guarantee that the compiler verifies for everyone: “let us demonstrate that this does not corrupt the memory we share.”

The functionality that seems the most authoritarian, the borrow checker, which can be exasperating, is, when read properly, deeply communal, because it fosters a care that each person used to carry alone. Rust’s character does not reside only in the community surrounding the code, but also in the relations the code itself establishes among those who write it.

Yet this socialization hides a price that, although perhaps not high, is worth naming: the borrow checker does not reject only what is dangerous. It also rejects programs that could be correct, even elegant, for the mere reason that their correctness cannot be demonstrated within its rules. It does not seem unreasonable to me to think that certain kinds of masterpieces, highly dependent on a fine choreography of memory and ownership, may be extraordinarily difficult to achieve under that discipline. Although unsafe exists for such cases, the door through which one says “I take responsibility here” is a narrow one, and the mere fact of having to cross it reminds us that every shared guarantee is purchased with a portion of individual freedom.

The safety the borrow checker gives us has a cost, and its cost is that some legitimate, and sometimes beautiful, ways of writing a program are pushed to the margins. I am not interested in resolving that tension; I would rather leave it alive, because it may be the language’s most polemical one. And yet I prefer to sacrifice an unknown but potentially dangerous mastery rather than allow a disaster to dwell hidden in production for years until some unexpected permutation, which no one managed to capture, finally reveals it. Because, my dear Cartesian friends, understand once and for all: not everything that can happen can be captured!

It is important, however, to tell properly where Rust comes from, because its history is neither that of a pure commons nor that of a creature of capital. Rust was born in the world of free software: it was incubated by Mozilla, which is itself the child of a free gesture — the opening of Netscape’s code — and is organized around a foundation with a mission, not the appetite of an ordinary company. Its foundational years took place there, not in the calculations of a shareholder. Only later, when that house had to retreat, did the language come to be sustained by its own foundation, backed by large technology corporations.

Today the capital of large corporations weighs on Rust. But it weighs on something it did not create: it arrived as support for a commons that already existed, not as its origin. The shared and capital ended up intertwined — let us hope for the better — but the order matters, and the order, first, was free.

And the irony goes further than large corporations and their capital. Today, I fear, even the military-industrial complex — or, less politely, the machinery of death — courts Rust: DARPA funds a program with a shamelessly candid name, TRACTOR (Translating All C to Rust), to rewrite the Pentagon’s old C in Rust and make it more reliable. One is almost tempted to wish they had stayed with C and C++, for the sake of peace!

But let us return to the idea of freedom in invention. Can you imagine if Rust’s creator had had to face managerial bureaucracy ruled by “business value,” or prior verification through long and tedious RFC processes? Rust probably would not exist, or someone else, with sufficient freedom, would have taken up the relay.

C++ was born inside a corporation — and one of the great ones: AT&T Bell Labs, the same world that years later preferred to keep Unix closed and litigate over it rather than open it. This reading does not come only from books. Between 1994 and 1997, as a student, I was at Chorus Systèmes, in the middle of one of those possible forks in the history of Unix. Chorus had been considered for the future Unix SVR5 of USL/Novell, within the Amadeus project. Then came the commercial advance of Windows NT, Novell’s retreat, the sale to SCO, and the dissolution of that possibility. I do not offer this as definitive historical proof; no one can know what would have happened. But it leaves me with a suspicion that is difficult to ignore: if that effort had been more open to collaboration, perhaps it would not have ended that way. In any case, the closure of Unix helped open space on two fronts: one free, Linux; the other proprietary, Windows NT and its successors. If either language bears a more corporate imprint at birth, it is C++, not Rust.

I do not deny that C++ contributed an enormous amount of common knowledge by revealing template metaprogramming and popularizing generic programming and object orientation. Libraries of very high quality, as well as the voluntary effort of Boost, are goods that belong to all of us. Rust is not clean of capital, and C++ was not devoid of community. But in its formative experience, Rust leaned toward the participatory and the hospitable, while C++ leaned toward the committee, the filter, and elitism.

The Highest Good: Working Together, Not Merely Side by Side

It is worth making a distinction that everyday language tends to erase, because not all sharing is the same: cooperating and collaborating are not identical.

Cooperation coordinates independent efforts toward compatible ends. Each person does his part, no one obstructs the other, and the whole benefits from the sum. It is additive, weakly coupled; its product can be separated into the parts that formed it. crates.io is, to a large extent, this: thousands of hands publishing in parallel, without co-writing anything with anyone.

Collaboration is something else, much deeper and more transcendent. It is co-labor over the same object: thinking together about a shared problem and producing something emergent that no one possessed separately and that bears the mark of the interaction. The design of a type system, an RFC matured by many minds, an abstraction that emerges alive from a rough discussion: that is collaboration. Its product is not separable. It is not “yours plus mine.” It belongs to all.

If I had to choose among the values of a technical culture, I would place collaboration far above everything else, especially above cooperation. Cooperation is important, necessary, and works in concert: protocols, noninterference, exchange, everything that allows many to scale without colliding. But creation, true creation, occurs one layer deeper, in co-labor: collaboration. Its Latin etymology is collaborare. The prefix con connotes “together,” and laborare, “to work.” We usually celebrate the open bazaar, which is above all that cooperative layer. But what truly makes production fertile is that several minds do not merely coordinate, but meet, complement one another through their diversity, enrich one another, and celebrate triumph and, at times, glory.

And here I must say the most uncomfortable thing, because without it everything above would be complacency. The disease I have been describing — the norm before practice, permission before experience — is agnostic with respect to technology. It does not reside in any language. It resides in a mode.

Much of Rust, although also of other languages, such as Ruby, for example, was born from collaboration, and part of my admiration comes from there. However, in other hands, it could cease to be a practice one chooses and become a norm one obeys. If that were to happen, it would commit exactly the sin I reproach in the committee that delays: authoritarianism before the merit of a good result, decree before experience. The same language I celebrate for having been born free could become an instrument of confinement without changing a single line of its grammar. What binds is not the tool itself, but the mandate. And the mandate can clothe itself in any language.

This applies both to languages and, above all, to organizations. An authority that imposes a tool on a practical community that did not participate in the decision does not merely restrict a technical freedom: it cancels the co-authorship of the decision. Where experience is available for collaboration, obedience is installed. And obedience, however well founded the order may be, always produces less than the meeting of silenced minds would have produced. Not because the order is necessarily wrong — sometimes it is right — but because it substitutes the highest good, collaboration, with the poorest of its substitutes.

Perhaps the lesson is not to replace one aristocracy or obedience with another. Technical creation needs freedom in order to be born, rigor in order not to corrupt itself, and collaboration in order to become great. The more freedom is absent, the more the new is restricted. If rigor is absent, the new can rot from within. If collaboration is absent, the work remains below what many minds could have produced together.

Here is what I believe is most transcendent: every creation is crossed by some form of collaboration. No one invents anything from nothing. Even the most solitary creation writes upon a collective memory made of languages, books, other people’s errors, teachers, companions, adversaries, and the dead who still speak to us through their works. Knowledge is cultural before it is merchandise, and collaborative before it is possession. Every decree that restricts collaboration in favor of obedience impoverishes, whether it comes from a committee, a tradition, or a hierarchy. The difference between the virtuous and the tyrannical is always played out in the same place: in whether minds met, or merely obeyed.

Rust fascinates me because it suggests that collaboration, not anarchy, when practiced with maturity and rigor, produces forms of engineering that isolated or closed authority struggles to imagine in time. And it reminds me of this de facto, through facts: compiling, functioning, entering slowly, even into the most conservative territories, with virtuous results.

It proves no doctrine. It does not need to. It proves something more modest and, for that very reason, more forceful: working together is not a naive ideal, but one of the most creative forces we know.

That proposition, simple as it may seem, is unbearable to any aristocracy that confuses commanding with creating.

About the Author

Leandro Rabindranath León is a Lead Software Engineer currently working in the sports betting industry at Genius Sports. With a deep-rooted background in the free software movement, a long history as a C++ practitioner, and as the creator of the Aleph-w data structures library, he is passionate about the intersection between high-performance systems programming and the human cultures that build them.

Translation Note: The original Spanish version of this essay was translated into English with AI assistance, trying that the spirit of the text remained fully intact.

DEV Community: Leandro Rabindranath León