For years, Stack Overflow’s annual developer survey asked tens of thousands of developers which programming languages they dreaded. Near the top of that list, again and again, sat MATLAB — a cloistered, expensive tool beloved by academics and reviled by nearly everyone else — alongside languages most developers under thirty have never seriously used, such as Visual Basic and COBOL. Yet here is the twist that haunts every computer science department and Silicon Valley boardroom: COBOL, the language routinely described as dead or dying since the 1980s, still runs an estimated 95 percent of ATM transactions and processes roughly $3 trillion in daily commerce. It is the lingua franca of the world’s financial plumbing, and there are fewer people who can write it every year.
The story of programming languages is not a clean Darwinian narrative where the fittest survive. It is messier, more political, and more accidental than that — a history shaped by corporate strategy, timing, community culture, and the stubborn weight of accumulated code. Languages that “won” often did so not because they were the best tools for the job but because they arrived at the right moment, were bundled with the right platform, or cultivated the right tribe of early adopters. And the languages that died frequently took genuinely good ideas with them, leaving their innovations to be rediscovered, sometimes decades later, by successors who got the timing right.
The Myth of Technical Superiority
Ask most programmers why Python became dominant, and they will tell you it is because Python is clean, readable, and beginner-friendly. There is truth to that. But consider: Ruby is equally readable. Scheme is more mathematically elegant. Haskell enforces a kind of intellectual purity that Python’s designers never even attempted. None of them came close to Python’s trajectory.
Python’s real breakthrough was not syntactic. It was strategic positioning at the intersection of three massive waves: the rise of scientific computing in academia, the explosion of web scripting in the early 2000s, and — most decisively — the machine learning revolution that began around 2012. When Google’s researchers and Stanford’s neural network labs started publishing code, they published it in Python. NumPy, SciPy, and eventually TensorFlow and PyTorch weren’t just libraries; they were gravitational fields that pulled an entire generation of scientists, engineers, and eventually corporate IT departments into Python’s orbit. By 2023, Python had climbed to the number one spot on multiple language indices, including the TIOBE Index, which tracks search engine queries as a proxy for language popularity.
The lesson is uncomfortable for idealists: technical excellence is necessary but rarely sufficient. ALGOL, developed in the late 1950s, was so technically ahead of its time that nearly every modern procedural language owes it a direct debt — yet it never achieved significant commercial adoption. Its fate is a reminder of how innovation in language design routinely outpaces the market’s ability to absorb it.
Platform Capture: The Most Powerful Force in Language History
If technical merit is overrated, platform capture is perhaps the single most underrated force in language survival. JavaScript is the most obvious example in history. By almost any aesthetic or technical measure, JavaScript is a deeply strange language — a product of ten famous days of development by Brendan Eich at Netscape in 1995, rushed to market for the Netscape browser. It has a type system that produces baffling results (the expression [] + {} returns "[object Object]", while {} + [] returns 0 in some contexts), inherits some design decisions from Java and some from Scheme, and spent its first decade being dismissed by serious programmers as a toy.
Today JavaScript is, by most metrics, the most widely used programming language on Earth. The Stack Overflow Developer Survey 2023 found it was used by 65.8 percent of professional developers — a number that has barely budged in over a decade of surveys because the browser remains the universal deployment target. Every website in the world needs JavaScript to function interactively. There is no alternative. That platform monopoly created the conditions for Node.js (JavaScript on the server), React and Angular and Vue (JavaScript frameworks), and an entire ecosystem worth hundreds of billions of dollars. The language did not win on merit. It won because it was there, embedded in every browser shipped with every computer sold.
Swift and Kotlin tell a more recent version of the same story. Both languages were introduced by platform owners — Apple and Google respectively — as replacements for aging predecessors (Objective-C and Java for Android). Both were technically superior to what they replaced. Both achieved rapid adoption not because developers independently discovered and embraced them but because the platform owners made them the path of least resistance. Apple built its newest frameworks, such as SwiftUI, around Swift; Google designated Kotlin as the preferred language for Android development. When the platform decrees, developers follow.
This dynamic helps explain one of the great puzzles of language history: why so many technically excellent languages failed. Erlang, developed at Ericsson in the 1980s for telecom switches, solved distributed concurrency problems in ways that still impress engineers today. It runs the messaging infrastructure for WhatsApp — at peak, a team of 50 engineers handled over 900 million users, partly because of Erlang’s architecture. But Erlang never had a platform patron to drive mass adoption. It remained the best tool for a specific class of problems, known to specialists, invisible to most of the industry.
The Ecosystem Problem: Why Batteries Must Come Included
In 2008, a language called D was supposed to be the next C++. It fixed many of C++‘s most notorious rough edges, had a cleaner syntax, and attracted enthusiastic early adopters. Andrei Alexandrescu, one of the most respected C++ authors in the world, joined the project. By almost any technical analysis, D should have displaced C++ in systems programming niches, or at least carved out a significant share of them.
It didn’t. One major reason: libraries. C++ had decades of battle-tested libraries for everything from graphics to networking to finance. D had almost none. And without libraries, the language couldn’t be used for real projects; without real projects, no libraries would be written. This chicken-and-egg problem is the graveyard of promising languages.
Go, the language Google released in 2009, was engineered from the start with this lesson in mind. It shipped with a comprehensive standard library covering HTTP, cryptography, JSON parsing, database interfaces, and more. It also came with opinionated tooling: a formatter (gofmt), a testing framework, a documentation generator, and a build system, all in the box. You could write a production web server in Go with zero external dependencies.
This philosophy — batteries included, tools bundled — has proven enormously influential. Rust, which Mozilla launched as a systems language focused on memory safety, took a similar approach. Its package manager, Cargo, is routinely described as one of the best dependency management tools in any language ecosystem, a remarkable distinction for a language that only reached version 1.0 in 2015. Rust has topped Stack Overflow’s “most loved” and later “most admired” language rankings every year from 2016 through 2025. Whether admiration translates into adoption at scale remains an open question — it is still used by a relatively small fraction of professional developers — but the ecosystem investment positions it well for the long game.
Community, Culture, and the Human Factor
Numbers and platform dynamics tell only part of the story. Programming language communities have cultures, and those cultures shape who joins, who stays, and ultimately whether the language grows or stagnates.
Perl is the cautionary tale here. In the 1990s, Perl was the internet’s working language. It powered CGI scripts, system administration, bioinformatics, and half the web’s back-end infrastructure. Larry Wall, its creator, was a beloved figure; the language’s culture was famously anarchic and creative, embodied in the motto “There’s more than one way to do it.” Perl embraced complexity and expressiveness to a degree that its practitioners celebrated as power and its critics condemned as write-only code — programs that even their authors couldn’t read six months later.
When Python emerged as an alternative with its commitment to clarity and “one obvious way to do it,” the cultural contrast was stark. Python communities welcomed beginners. Perl communities, while not hostile, could be dense and insider-focused. As web frameworks like Django and Ruby on Rails offered cleaner abstractions than Perl’s CGI model, developers migrated. Perl’s core developer community fractured during the decade-long development of Perl 6 (later renamed Raku), a redesign so ambitious and so prolonged that many in the community lost faith entirely. By the time Perl 6 shipped in 2015, the world had moved on.
Ruby offers a counterpoint — and a warning. It achieved enormous popularity through Rails, the web framework that defined rapid application development in the mid-2000s. Startups like Twitter, GitHub, and Shopify were built on Ruby on Rails. Ruby’s community, shaped by designer Yukihiro Matsumoto’s philosophy of “programmer happiness,” was enthusiastic and welcoming. But Ruby’s performance limitations, combined with the rise of JavaScript on the front end and Go and Python on the back end, have eroded its position. Twitter, one of its most prominent early champions, famously moved its performance-critical back end off Ruby to the Java Virtual Machine. The language survives — Shopify still runs primarily on Rails and has invested heavily in making Ruby faster — but the growth trajectory has reversed.
What Kills Languages: The Slow Deaths and the Sudden Ones
Languages rarely die dramatically. They fade into maintenance mode, their user bases aging, their job postings dwindling, their Stack Overflow questions going unanswered for days rather than minutes. The mechanisms are consistent.
Abandonment by a platform owner can be swift and decisive. Microsoft’s decision to effectively deprecate VBScript in favor of C# and later PowerShell was a death sentence for a language that had powered millions of web applications. Flash’s ActionScript, once the language of interactive web experiences, was eliminated when Adobe and Apple’s infamous feud over Flash on iOS led to its removal from mobile devices, and eventually from the web entirely. The entire ActionScript ecosystem — games, interactive graphics, educational software — was simply deleted from relevance by a business decision.
Fragmentation is a slower poison. ColdFusion, a web development language popular in the late 1990s and early 2000s, never quite died but was handed between corporate owners — Allaire, Macromedia, Adobe — each with different priorities, leaving developers uncertain about the language’s future. Uncertainty breeds hedging: developers learn alternatives, new projects choose safer bets, and the installed base slowly erodes without ever collapsing.
The successor problem is perhaps the cruelest form of language death. Python 3 was released in 2008, breaking backward compatibility with Python 2. The migration took until 2020 — twelve years — during which time the community was split between incompatible versions of the same language. Python survived the schism only because of its enormous momentum and the concentrated effort of organizations including the Python Software Foundation and major cloud providers. Perl’s equivalent transition did not survive.
The Next Contenders: What Survival Looks Like Now
Looking forward, several dynamics are reshaping the competitive landscape. Rust is the most discussed potential disruptor in systems programming. The White House’s Office of the National Cyber Director published a report in 2024 explicitly recommending that developers migrate away from memory-unsafe languages like C and C++ — a remarkable government endorsement of a specific language ecosystem. The Linux kernel, the most consequential C codebase in the world, accepted Rust as its second official language in 2022, and in 2025 its developers declared Rust support no longer experimental. If memory safety becomes a regulatory or procurement requirement for critical software, Rust’s adoption curve could steepen sharply.
TypeScript — technically a superset of JavaScript rather than an independent language — represents a different model: evolving an existing dominant language rather than replacing it. By adding optional static typing to JavaScript, TypeScript gave enterprise developers the safety guarantees they needed while preserving the platform advantages and library ecosystem that JavaScript had spent decades accumulating. Adoption has been rapid: the majority of large JavaScript projects now use TypeScript, and major frameworks like Angular made it their default. This is perhaps the most important recent lesson in language evolution: sometimes the smartest strategy is not disruption but enhancement.
Meanwhile, the AI coding revolution is introducing its own strange pressures. Tools like GitHub Copilot and OpenAI’s Codex generate code in any language a developer specifies, theoretically lowering the cost of working in less-popular languages. If an AI can scaffold a Haskell application or write idiomatic Erlang on demand, does ecosystem disadvantage matter less? Perhaps. But the same tools were trained predominantly on the vast GitHub repositories of Python, JavaScript, and Java — meaning they are far more capable in those languages than in obscure ones. Popularity breeds AI capability, which breeds more popularity: a feedback loop that may accelerate consolidation around today’s dominant languages rather than democratizing the long tail.
The history of programming languages is, in the end, a history of human decisions compounding over decades. The languages that endure are not simply the best-designed ones — they are the ones whose communities, ecosystems, and platform relationships created enough gravitational pull to make switching away more painful than staying. That is not a comforting conclusion for those who believe good ideas should win. But it is an accurate one. And buried in that observation is perhaps the most useful advice anyone has ever given about building a programming language: write the libraries first, find the platform second, and worry about the syntax third.