Rust was a great social experiment. But like the Mozilla Foundation that birthed it, the Rust Experiment has failed.
Rust has been in development for nearly two decades. Graydon Hoare began it as a personal side project in 2006, frustrated with brittle systems software. Mozilla provided official sponsorship starting in 2009, turning it into a funded effort aimed at safer systems programming. The first stable release arrived in 2015. By 2021, after Mozilla layoffs, the Rust Foundation took over with backing from big tech. That timeline spans personal tinkering, corporate incubation, and foundation stewardship—roughly 17–20 years depending on where you start the clock.
In that time, Rust has not delivered several foundational capabilities expected from a mature systems language. These gaps are not minor polish items. They limit real-world use in kernels, embedded systems, libraries, and high-performance infrastructure where predictability and interoperability matter most.
Missing Milestones
A stable ABI. Rust produces binaries, but the Application Binary Interface remains unstable. This blocks reliable shared libraries, dynamic loading, and seamless interop with other languages without heavy wrappers or version pinning. Discussions in the community still treat a stable ABI as a distant wish-list item rather than a delivered feature. Without it, Rust struggles to become a drop-in component in larger ecosystems that rely on binary compatibility across releases or vendors.
Cached builds that just work. Incremental compilation has existed in some form since around 2016, and Cargo offers caching mechanisms. Yet rebuild times remain a frequent pain point in large codebases, especially when dependencies shift or when moving between debug and release profiles. Full, reliable, project-wide caching that survives clean builds, CI environments, and cross-machine sharing has not reached the level of maturity seen in other toolchains. The result: slower iteration cycles than the language's safety promises would justify.
Constant evaluation power. Rust's const fn and compile-time evaluation have grown, but they remain sharply restricted. Many operations that should be feasible at compile time—loops with non-constant bounds in earlier versions, floating-point math in some contexts, or broader interpreter capabilities—still hit walls. The const evaluator is deterministic by design, which is correct for soundness, but the practical power lags behind what systems programmers need for zero-runtime-overhead configuration, tables, or invariants.
Compile-time metaprogramming. Rust relies on declarative and procedural macros. These work for many tasks but feel like a bolted-on solution rather than a cohesive system. Procedural macros require separate crates, operate on token streams or ASTs with hygiene considerations, and lack the seamless, hygienic power of true compile-time code generation found in some other languages. Reflection remains absent. The result is verbose workarounds and debugging friction that discourages deep metaprogramming where it could eliminate boilerplate or enable powerful domain-specific abstractions.
And more: challenges with certain linking scenarios (ELF details on non-standard targets), allocator flexibility that has taken years to approach stabilization, and a general sense that foundational systems plumbing trails the hype around memory safety.
Root Causes
These shortfalls stem primarily from three intertwined issues.
Addiction to small things over critical things. Development energy has often flowed toward ergonomic wins, syntax tweaks, edition changes, and ecosystem growth. These are visible and attract contributors. Harder, less glamorous work—stabilizing ABI contracts, hardening the const evaluator against edge cases, or overhauling caching for consistent performance—moves slower. The project's stability guarantee (once something stabilizes, it stays) is a strength, but it also raises the bar so high that risky foundational changes get deferred indefinitely. Nice-to-haves ship faster than must-haves for systems work.
Community issues. Rust's community is large, passionate, and opinionated. That brings energy but also bikeshedding, governance friction, and a culture where certain directions face resistance. Discussions around ABI stabilization or loosening const restrictions sometimes stall in RFC processes or team consensus. The "most loved" language status in surveys coexists with vocal subsets prioritizing purity or specific visions over pragmatic delivery. Newcomers and industry users pushing for production hardening can feel sidelined by those focused on language aesthetics.
Management issues. Mozilla incubated Rust with a browser-centric lens—Servo and Stylo were key testbeds. After the foundation shift, multiple corporate sponsors joined, each with their own priorities. Steering a project with this history requires clear, decisive leadership on trade-offs. Instead, the process has often felt consensus-driven to a fault, leading to incremental progress on popular features while core systems deficiencies linger. Graydon Hoare stepped back years ago; subsequent leadership navigated growth but did not force the hard resets needed for a true systems-language foundation.
Rust delivered undeniable wins: excellent memory safety without garbage collection, strong concurrency primitives, and a borrow checker that catches classes of bugs at compile time. It displaced or supplemented C/C++ in niches like Firefox components, cloud infrastructure, and embedded work. Adoption grew because safety matters and the toolchain improved iteration for many teams.
Yet the original promise was a better foundation for systems software—reliable, interoperable, and powerful enough to replace existing tools without compromise. On that metric, after two decades, the experiment has not succeeded. The language excels at being safe and concurrent but falls short as a complete, no-excuses systems platform.
I have forked Rust and embedded many of the tools into the new repo, named Forge. Forge will maintain a compat layer with a “stable" version of rust, but only so much as to use “rust" code and compile rust projects.
The Point of Forge
As with all bad ideas, this one has Good intentions. Forge aims to implement the basic features that Rust lacks and also solve some key problems in Rust (and C and similar languages as a result)
Forge will impose a typeset and typesystem that is able to be easily understood by humans and machines alike. A big problem with Rust is the learning curve. There are so many things you need to learn about so many things that it's recommended you are proficient in C and Haskell before learning Rust. Forge aims to change that.
Forge also plans on embracing the Future in a way that gives us legal protections against the AI companies that Rust didn't have and has proven a detrimental part of their history. Forge, via the holding entity AWFixer Holdings LLC will pursue an internal model, editor and other Tools that you cannot use Forge to develop competing products for. (With reasonable exceptions related to non-AI enabled tooling like SAST).
Forge will be given 5 practical and functional tasks as we build it to help us understand improvements needed and guidance in changes we make.
Task One: We have been working on a browser engine (called browse) and while we will actively work on transpiling and rewriting the project to Rust we will also begin migrating to Forge pending completion of the migration and work in Forge indicating that it's ready to be used in this way.
Task Two: we have also been pondering the building of a new version of git, one we are calling SRC (because naming things is hard). We plan on adding more features related to concurrency and web APIs to Forge and so this will help use see how we are doing in that regard.
Task Three: we are working on a suite of Operating Systems. We believe that Microsoft is wrong about their vision for operating systems and as we grow our species, both terrestrially, extraterrestrially and in the digging of holes a new suite of stable and specialised operating systems will be needed. Forge will be employed to power 2 portions of the suite. This task relates to the Desktop Environment. We believe that moving forward desktop environments will need to provide more features then they currently do and support broader use cases then they currently do. In order to support this they need a language foundation that is more flexible than they currently have. E.g. we have Gnome. Written in C. Extensions are limited in function and stability and are written in primarily JavaScript via GJS, Thus making GNOME extensibility a living hell. KDE Plasma is not much better. It provides better extendability but at the cost of overall performance and stability. That should change, and with our Forge powered Desktop Environment it will.
Task Four:
Task Five: