# Did AI Kill the Software Ecosystem Moat? > Source: > Published: 2026-07-13 21:35:13.404954+00:00 # Did AI Kill the Software Ecosystem Moat? June 18, 2026 I chose my software languages for their network effects, and it was the right call. Then AI and the collapsing cost of rewrites inverted the economics, and the primary consideration is now performance. We've all heard the cliché: use the best tool for the job. That advice is easy to follow when you're building physical things, where the best tool is usually obvious. In the BC (Before ChatGPT) software world, the best software for the job was primarily dictated by [network effects](/glossary#network-effects). The bigger an ecosystem, the more valuable it was. More developers knew the syntax, so more tooling and support got built around it. That pulled more systems onto the software, which opened more jobs for it, which drew in more developers. A continual feedback loop, each turn feeding the next. I lived inside that loop. I generally reached for whichever framework had the biggest ecosystem unless a unique problem required something else. It was [Metcalfe's law](/glossary#metcalfe's-law) pointed at a language instead of a phone network: the value of knowing a thing grew with the square of the number of people who already knew it 1. That wasn't a compromise. It was the correct call. Betting on the biggest network was the rational move. The ecosystem was the product. Then agentic coding arrived and the economics of choosing software changed with it. Humans are no longer the bottleneck in producing software. The constraint slides down to the next scarce thing: compute. And compute is genuinely scarce now, not because chips stopped getting cheaper, but because demand keeps outrunning them. Efficiency only feeds it, through [Jevons paradox](/glossary#jevons-paradox): every gain in how cheaply we can run a model just invites us to run more, the way more efficient steam engines burned more coal, not less 2. Every token of inference, every agent running in a loop, every model in production fights for the same silicon and the same power, and the datacenters can't go up fast enough. When compute is the binding constraint, lightweight and fast stop being preferences. They become the whole game. At the same time, the cost of a software rewrite has collapsed. The gravity of those old networks is starting to crack: it only held because human cognition was the bottleneck, and that bottleneck is lifting. The economics of software engineering have changed. The familiarity moat is gone. You no longer need a generation of engineers who already know a language for that language to be viable, because the model already knows it, or can learn it quickly. The decade-deep moat is now a rounding error. So line the forces up. Compute is scarce and getting scarcer. Familiarity is cheap. Rewrites are cheap. Put those three together and the whole landscape tilts one way, toward leaner, faster, more efficient software, and it's hard to see what tilts it back. That's the shift worth watching. The question stops being "what does everyone know?" and becomes "what actually runs best?" The gravity was never about the language. It was about the network around it. And the network, it turns out, was only load-bearing because of the human cognition + production bottleneck. So for the first time, "best software for the job" can mean the actual software, not the ecosystem around it. ## Two forces Two forces decide which languages live and which fade, and AI only kills one of them cleanly. The first is familiarity: the private cost each engineer pays to become productive in a language. For fifty years it quietly governed most technology choices. AI drives that cost toward zero. You no longer learn the language. The model already did. The second is the one I just described, and it's sturdier. There's a name for its surface form: the [Lindy effect](/glossary#lindy-effect), the rule that the longer a technology has already survived, the longer it's likely to keep surviving 3. COBOL has been dying for forty years and it's still here. But age is only the proxy. What Lindy is really measuring is the network around a language, and that network has two layers. There's the human layer I bet my career on: developers, tooling, jobs, the gravity of everyone choosing the same thing. Underneath it sits a machine layer that outlasts the people. Every system running a language becomes a dependency, and other systems depend on those, until the web is structurally impossible to remove. Not age. [Embeddedness](/glossary#embeddedness). That web is what keeps the old guard alive. For now. You'd think you could see its weight in the raw line counts, but most counts are unreliable guesses, since the bulk of production code is private and never measured. The one number that actually holds up is COBOL: an estimated 220 billion lines still in production, steady across decades of independent estimates 4. For everything else, no single figure captures what a language is, so ask four different questions and you get four different winners: | Question | What it measures | Who wins | |---|---|---| | Where's the human labor? | active developers | JavaScript (~22.5M), then Java (~17.5M), Python (~16.8M) | | What's deployed everywhere? | reach | PHP runs ~70% of the server-side web; Oracle claims 73 billion running JVMs | | What's being worked on now? | repo activity | Python passed JavaScript on GitHub in 2024; TypeScript passed both in 2025 | | What burns the least compute? | energy per task | C, with Rust within 3 percent | COBOL wins none of them: almost no new developers, near-zero public activity, nothing new deployed on it. It wins the one metric on no chart, code that's still load-bearing and can't be pulled out. That's the dependency web, invisible to every popularity ranking by design. So: AI tells you which new tools are finally viable. The web tells you which old ones refuse to leave. Everything interesting happens where they collide. ## Where the new tools win One example proves the switching cost collapsed. The rest show what you'd switch to. ### Bun bets a million lines on it If you want the clearest possible evidence that the cost of switching just collapsed, look at what happened to Bun this spring. On May 4, 2026, Jarred Sumner committed a 576-line file called `PORTING.md` to the Bun repository 10. It's not a manifesto. It's an instruction sheet, and the audience isn't human. It opens, roughly, with "you are translating one Zig file to Rust," and proceeds through a crate map, a type map, an allocator strategy, and the FFI patterns needed to port Bun's entire runtime from Zig to Rust, file by file, using Claude. Ten days later, a pull request titled "Rewrite Bun in Rust" merged into canary 11. Roughly a million lines. Over six thousand commits. A runtime, ported between two systems languages, in a week and a half, mostly by a model. Then look at what Sumner said when people lost their minds over it. Not a grand thesis about Rust's superiority. The opposite: "We haven't committed to rewriting. There's a very high chance all this code gets thrown out completely." Sit with that. A team attempted a full-runtime language migration on a hunch, with no commitment, fully prepared to throw the result away. That posture was unthinkable two years ago, when a rewrite like this was a multi-year, bet-the-company decision. The rewrite isn't the story. The *casualness* is the story. When trying costs orders of magnitude less, you try things you'd never have dared to schedule. ### Backend: Python and Rust I built the same service twice, once in Python with FastAPI, once in Rust with Axum. One endpoint, returning `{"message": "hello"}` . | Metric | Python | Rust | |---|---|---| | Docker image | 130 to 180 MB | ~2 to 15 MB | | Cold start | 200 to 2000 ms | 1 to 10 ms | | Throughput (TechEmpower JSON) | ~177K req/s | ~1.14M req/s | The throughput comes from TechEmpower's JSON serialization benchmark, the final round before the project was archived 12. Treat the digits as approximate and the image and cold-start numbers as estimates. The ratios hold: about six times the throughput, an order of magnitude smaller image, a hundred times faster to start. The Rust binary is a compiled static artifact. The Python service drags CPython, uvicorn, and FastAPI behind it before your code runs. The benchmarks aren't the real evidence, though. The migrations are. Discord moved a core service from Go to Rust because Go's garbage collector forced a collection every two minutes, scanning an entire cache to decide nothing needed freeing. The Rust version, in their words, "had no latency spikes," and they "beat Go on every single performance metric. Latency, CPU, and memory were all better" 13. Dropbox rewrote their sync engine from Python to Rust after they "failed to appreciably scale" through months of optimization, and called Rust "a force multiplier" . [14](#user-content-fn-dropbox)No collector. No interpreter. No cold-start tax. Compiled code doing what you told it, at the speed of the hardware. ### Frontend: React and Svelte React ships a runtime. Load a React app and the browser pulls down roughly 42 KB of framework, gzipped, before anything renders. Svelte's runtime is about 2 KB 15. Not the page. The framework. The difference is architectural. Svelte is a compiler. It turns your components into surgical DOM updates at build time and ships almost nothing. React ships a reconciler that diffs a virtual DOM in the browser on every update. One does the work before the user arrives. The other does it on the user's device, on the user's battery. Across the benchmarks, Svelte runs meaningfully faster and leaner than React on the same workload, with Vue sitting in between 16. When the user has a fast machine and a fast network, the gap is academic. That's not the world we're building for. Every millisecond burned in the browser is a millisecond the device could have spent on the actual experience. ### Desktop: Electron (JavaScript) and Tauri (Rust) Electron bundles an entire copy of Chromium with every app. Tauri uses the operating system's own WebView and ships a static binary instead. A minimal Tauri app is around 3 MB. The Electron equivalent runs somewhere from 80 to 150 MB, so Tauri is roughly 30 to 50 times smaller, and idle memory follows the same shape, with the largest gap on Linux 17. No major Electron app has rewritten itself in Tauri yet, because the porting cost has, until very recently, been too high to justify. But the third-party clients show the ceiling. Dorion, a Tauri-based Discord client, runs far lighter than the official Electron app 18. That's not optimization. That's architecture. ### Cloud infrastructure: Go, and why it isn't Rust yet Lean and fast already won an entire domain once, years before AI, and it won with Go. Docker, Kubernetes, Terraform, Prometheus, etcd, the cloud-native stack is Go top to bottom 19. Infrastructure is the one place performance always mattered, so the lean tool won there while familiarity was still expensive everywhere else. Go beat Python and Java on exactly the logic this essay runs on. Which raises a fair objection. I just told you Discord rewrote a service from Go to Rust for performance. So why isn't the cloud written in Rust? Three reasons, and together they are the thesis in miniature. Timing: Docker shipped in 2013, Kubernetes in 2014, and Rust didn't reach 1.0 until 2015. The stack was built in the best tool that existed, then got embedded, the same way banking got stuck on COBOL. Sufficiency: Go's garbage collector is good enough for most of it, and the Discord rewrite was one latency-critical service whose huge cache fought the collector, not a verdict on Go itself. Cost: rewriting Kubernetes in Rust before AI meant years of work and a trust cost spread across every tool that depends on it. Familiarity was expensive and the rewrite was expensive, so the web held. And now Go is its own web. New infrastructure gets written in Go because the libraries and the hiring pool are Go. It got embedded the way the old guard did, a younger COBOL for one domain. So Discord isn't the exception that beats Go. It's the leading edge of the crack. The performance pressure is real and Rust wins where the collector bites, but the rest of the stack stays Go for now, held in place by the same two forces AI is dissolving everywhere else. The honest answer to why the cloud isn't in Rust is that *yet* is doing all the work in the sentence. ## Where the network is undefeated Now the honest counterweight. For a large class of software, none of the above matters, because the dependency web is too thick to cut. AI doesn't displace these systems. It helps maintain them. **C++ owns the GPU.** Not because it's pleasant, but because every interface to the hardware ships C or C++ headers. CUDA is C++. Vulkan is C. DirectX 12 is C++ COM. Metal is Objective-C and C++. The inference runtimes everyone depends on, llama.cpp and TensorRT, are C++ 20. Rust bindings exist, but no console vendor ships an official Rust SDK, and the high-level safe wrappers trade away the proximity that made C++ worth tolerating. Unreal Engine is an estimated several million lines of C++. AI lowers the cost of translating it. It does nothing about the cost of *trusting*the translation across fifty hardware configurations. C++ isn't going anywhere. **Java is the COBOL of the 21st century.** Critical, everywhere, unexciting. It modernized well: native images cut cold start from seconds to tens of milliseconds, and virtual threads landed in JDK 21 and took the sting out of concurrency 21. Spring Boot still anchors most new enterprise work. But "still the default for the enterprise" and "the right choice for a greenfield project" are different sentences, and the gap between them is widening. **COBOL outlasts all of it.** Roughly 220 billion lines of it run the world's banks and governments, a figure that's held across independent estimates for decades 4. You don't rewrite that. You wrap it, you translate new features off it, and you keep the lights on. The dependency web is the entire point. Those lines are load-bearing for the actual economy. **PHP is the web's COBOL.** It runs something like 70 percent of the server-side web, and it didn't win that by being fast 6. PHP is mid-tier, the same broad class as Node, both far behind anything compiled. It won on WordPress and twenty years of cheap shared hosting, a pure network effect with almost no performance case beneath it. That is exactly why it stays. The web is built on PHP, so the web keeps building on PHP. Modern PHP is far better than its reputation, but nobody picks it greenfield for speed. They pick it because the CMS, the host, and the tutorials already assume it. There is one bright spot in the new-versus-old fight that costs nothing and gives everything: TypeScript. It compiles away to identical JavaScript, so the runtime cost is zero, and the type system catches a measurable share of real bugs before they ship. A study of public bugs found TypeScript would have caught about 15% of them at compile time 22, and Airbnb's post-mortem of its own history found that 38% of past bugs were preventable by types . In a world where a model writes the first draft of your code, the compiler becomes the cheapest reviewer you have. It catches the hallucination before the test does. [23](#user-content-fn-airbnb)## The part I'm less sure about Here's the bet. Two things kept slower software alive. Familiarity, the private cost of learning, and the network web, the public cost of everyone else depending on it. AI already killed the first. What I didn't expect is how fast it would start eating the second. The web was never permanent. It was more like molasses: it doesn't stop change, it just slows it to a crawl. And it only stayed that thick because rewriting was expensive. Bun just showed that assumption dissolving. When a runtime can be ported between languages in ten days, every dependency in that web becomes negotiable in a way it never was before. But it doesn't vanish, and the reason is the same line I used to wave off C++. A rewrite is now cheap to *draft* and still expensive to *trust*, and the trust cost scales with blast radius. Drafting the new code is the part AI just made nearly free. Proving it behaves identically across every caller, every edge case, every production load is the part that didn't move. For a weekend project that cost is nothing. For a banking core it's everything. So the web goes porous, not gone: the bigger and more load-bearing the system, the more the trust cost still protects it. Follow that out far enough and the conclusion is uncomfortable. Where performance matters, it stops losing to familiarity, and the set of places where performance matters keeps widening as compute gets scarcer. Once familiarity is cheap and a rewrite is easy to draft, the only thing still holding slower software in place is the cost of trusting its replacement. The drift is uneven, but it has a direction: toward whatever burns the least compute, wherever the blast radius is small enough to risk it. Greenfield first. The load-bearing legacy last, if ever. The part I find most interesting is what comes after porting. If you can rewrite a runtime in a weekend of compute, you can also afford to invent one. For decades a new language died on adoption, because adoption meant a generation of engineers paying the familiarity tax and a fresh ecosystem built from nothing. Both of those costs are collapsing at once. So I think we're about to see languages designed performance-first, written by models and run on hardware, unburdened by any need to feel familiar to a person. What does a language look like when no human has to love it? Maybe it drops the syntactic sugar that exists only so we can read it faster. Maybe it's verbose and painfully explicit in ways that would exhaust a person but suit a model that never gets tired or bored. Maybe it optimizes for what a compiler can prove rather than what a reviewer can skim. Zig was a clean C replacement designed for humans. The next one might not be designed for humans at all. I don't know which of these lands. But the direction feels set. ## What I'd pick, and what picks itself If familiarity is cheap and the web is porous, "best software for the job" finally means what it always pretended to: the software that burns the least compute, provided it's stable enough to build on. When I'm starting fresh, here's what I'll reach for: | Building new | I pick | Why | |---|---|---| | Backend service | Rust | Throughput, tiny images, no cold-start tax | | Frontend app | Svelte and TypeScript | Compiler over runtime, types catch the hallucinations | | Desktop app | Tauri | A few MB instead of a few hundred | | Systems code | Rust | Native speed, memory safety, no runtime | | JS runtime | Rust, as a bet | Bun is porting to it, but hasn't committed | When I'm not starting fresh, the choice is mostly made for me, by embeddedness, not by merit: | Domain | What holds | Why | |---|---|---| | Cloud infrastructure | Go | It already owns the ecosystem, for now | | Game or ML engine | C++ | The GPU speaks C++ and only C++ | | Enterprise monolith | Java | Too much depends on it, and it modernized | | Existing web or CMS | React/PHP | Already running most of the web | | Banking core | COBOL | Too much of the economy runs on it to risk the rewrite | | Embedded | C | The vendor toolchain decides, not you | The rule underneath both tables is short. For anything new, pick the software that burns the least hardware and is mature enough to trust. For anything old, respect the embeddedness: it survives not because it's best, but because too much still depends on it to pull out, at least until a rewrite gets cheap enough to be worth the risk. The learning curves are gone, AI ate them, and the rewrites get cheaper every month. The only thing still holding old software in place is the weight of everything depending on it, and that weight only ever mattered because moving it was expensive. That just stopped being true. The moat isn't dead, but it's eroding. Best software for the job is finally a question about the software. ## Footnotes - ["Metcalfe's law"](https://en.wikipedia.org/wiki/Metcalfe%27s_law).*Wikipedia*. The value of a network grows with roughly the square of the number of participants. Applied here to language ecosystems: developer base, tooling, and job market compound on one another.[↩](#user-content-fnref-metcalfe) - ["Jevons paradox"](https://en.wikipedia.org/wiki/Jevons_paradox).*Wikipedia*. When a resource is used more efficiently, total consumption tends to rise rather than fall, because the efficiency makes it cheaper to use. Named for William Stanley Jevons, who observed that more efficient steam engines increased coal consumption.[↩](#user-content-fnref-jevons) - Taleb, Nassim Nicholas (2012). *Antifragile: Things That Gain from Disorder*. Random House. Source of the Lindy effect as applied to the life expectancy of non-perishable things, including technologies and ideas.[↩](#user-content-fnref-lindy) - The roughly 220 billion lines figure for COBOL in production is consistent across independent estimates: Reuters (2017, ~220 billion), a Gartner baseline from the 1990s (~220 billion), and the Open Mainframe Project (~250 billion upper bound). A higher 800 billion figure also circulates, from a 2022 Vanson Bourne survey [commissioned by Micro Focus](https://www.prnewswire.com/news-releases/cobol-market-shown-to-be-three-times-larger-than-previously-estimated-in-new-independent-survey-301475439.html), a vendor that sells COBOL modernization tooling, so it reads as a sponsored self-report rather than a census. No language has a true line-count census, since most production code is private and never measured; COBOL is the rare case anyone bothered to estimate at all.[↩](#user-content-fnref-cobol)[↩](#user-content-fnref-cobol-2)2 - SlashData / DeveloperNation, ["Language Communities" update](https://www.developernation.net/blog/language-communities-an-update/)(Q3 2023). Survey-extrapolated estimates of active developers per language: JavaScript ~22.5 million (largest for six straight years), Java ~17.5 million, Python ~16.8 million, C++ ~10.3 million, Rust ~3.5 million (up 31 percent year over year). Model-based estimates counting anyone who used the language, not a census. SlashData puts the total global developer population near 47 million; JetBrains, counting professionals only, puts it near 20 million, which shows how much the definition drives the number.[↩](#user-content-fnref-slashdata) - ["Usage statistics of server-side programming languages"](https://w3techs.com/technologies/overview/programming_language/).*W3Techs*. PHP is used by roughly 70 percent of all websites whose server-side language is detectable, which is itself a subset of all sites. CMS fingerprinting (WordPress, Drupal, Joomla) biases the figure upward, so read it as web reach, not total deployment.[↩](#user-content-fnref-w3techs)[↩](#user-content-fnref-w3techs-2)2 - ["Java"](https://www.oracle.com/java/).*Oracle*. Oracle claims "more than 73 billion Java Virtual Machines" running worldwide. This counts JVM process instances, not devices, and is an unaudited vendor figure with no published methodology. It is a separate claim from the older, frozen "3 billion devices run Java" marketing slogan, which sat unchanged for over a decade.[↩](#user-content-fnref-jvm) - ["Octoverse 2024"](https://github.blog/news-insights/octoverse/octoverse-2024/)and["Octoverse 2025"](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/).*GitHub*. Python overtook JavaScript as the most-used language on GitHub in 2024; TypeScript passed both by August 2025 (2.64 million monthly contributors). Ranked by contributor and activity counts, not lines of code, and the leader changes depending on the sub-metric, since JavaScript still led on code pushes alone in 2024.[↩](#user-content-fnref-octoverse) - Pereira, Rui; et al. (2017). ["Energy Efficiency Across Programming Languages"](https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf).*SLE 2017*. Normalized energy on the Computer Language Benchmarks Game, with C as the 1.00 baseline: Rust 1.03, C++ 1.34, Java 1.98, JavaScript 4.45, Python around 76. A 2024 University of Massachusetts replication ([van Kempen et al.](https://arxiv.org/html/2410.05460v1)) argues the gaps largely track runtime and implementation rather than the language name itself, so read the ordering as compiled runtimes versus interpreted ones, not an intrinsic property of the syntax. The directional claim, that a compiled static binary burns far less than an interpreter doing the same work, survives the critique.[↩](#user-content-fnref-energy) - Sumner, Jarred (2026). ["docs: add Phase-A porting guide"](https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd5730ef1549e88407701a5).*GitHub, oven-sh/bun*. Commit 46d3bc2 adds the 576-line docs/PORTING.md, an instruction set for an AI-assisted Zig-to-Rust port.[↩](#user-content-fnref-porting) - ["Rewrite Bun in Rust"](https://github.com/oven-sh/bun/pull/30412).*GitHub, oven-sh/bun*. Pull request #30412, merged to canary on May 14, 2026, roughly one million lines across more than 6,000 commits, from branch claude/phase-a-port. Stable releases continued on the Zig line.[↩](#user-content-fnref-bunpr) - ["Web Framework Benchmarks, Round 23"](https://www.techempower.com/benchmarks/).*TechEmpower*. JSON serialization test. Round 23 (2025) is the final round before the continuous benchmarking project was archived. Exact figures are approximate and hardware-dependent.[↩](#user-content-fnref-techempower) - ["Why Discord is switching from Go to Rust"](https://discord.com/blog/why-discord-is-switching-from-go-to-rust).*Discord Engineering*, 2020. The Read States service migration, completed in 2019.[↩](#user-content-fnref-discord) - ["Rewriting the heart of our sync engine"](https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine).*Dropbox Tech*, 2020. The Nucleus rewrite from Python to Rust.[↩](#user-content-fnref-dropbox) - Framework bundle sizes are gzipped, framework-only, for a minimal app. React with ReactDOM lands around 42 to 45 KB, Vue around 16 KB, Svelte around 2 KB. Figures vary by build and version. [↩](#user-content-fnref-bundle) - Krause, Stefan. ["js-framework-benchmark"](https://github.com/krausest/js-framework-benchmark). The relative ordering, Svelte fastest and leanest, React slowest and heaviest, Vue in between, is consistent across runs. Absolute timings shift between versions, so they are best read as ratios.[↩](#user-content-fnref-krausest) - ["Tauri"](https://tauri.app/)and independent benchmarks (levminer, gethopp). Minimal Tauri apps run around 3 MB versus roughly 80 to 150 MB for Electron. Idle-memory comparisons come from single-machine benchmarks; the largest gap appears on Linux.[↩](#user-content-fnref-tauri) - ["Dorion"](https://github.com/SpacingBat3/Dorion). A Tauri-based Discord client, reported to use a fraction of the official client's memory. Usage-dependent, not a controlled benchmark.[↩](#user-content-fnref-dorion) - The cloud-native stack is overwhelmingly Go: Docker, Kubernetes, Terraform, Prometheus, etcd, and CockroachDB are all written in it. Go was released by Google in 2009 (reaching 1.0 in 2012) specifically for networked systems work, which is part of why it took the domain. Rust did not reach its 1.0 release until 2015, after the foundational cloud tools were already built. [↩](#user-content-fnref-goinfra) - NVIDIA CUDA (C++), the Khronos Vulkan specification (C), Microsoft DirectX 12 (C++ COM), and Apple Metal (Objective-C and C++). The widely used inference runtimes llama.cpp and TensorRT are C++. [↩](#user-content-fnref-gpu) - GraalVM native-image reduces JVM startup from seconds to tens of milliseconds. Virtual threads shipped in JDK 21 ( [JEP 444](https://openjdk.org/jeps/444), September 2023). Spring Boot adoption from the JetBrains developer ecosystem surveys.[↩](#user-content-fnref-java) - Gao, Zheng; Bird, Christian; Barr, Earl T. (2017). ["To Type or Not to Type: Quantifying Detectable Bugs in JavaScript"](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/gao2017javascript.pdf).*ICSE 2017*. Both TypeScript and Flow detected about 15% of public bugs that survived testing and review.[↩](#user-content-fnref-totype) - Bunge, Brie (2019). ["Adopting TypeScript at Scale"](https://www.youtube.com/watch?v=P-J9Eg7hJwE).*JSConf Hawaii*. A post-mortem of Airbnb's historical bugs found 38% were preventable by TypeScript.[↩](#user-content-fnref-airbnb)