Ninety-seven point two percent of all public Ruby repositories on GitHub had no new commits for six months. That's not a language in decline, that's a language in a museum with the lights off. Daniel's prompt this week is about the other side of the AI coding boom. We talk constantly about Python and TypeScript eating the world. He wants to know what's getting eaten. Which languages are actually trending downward, where we're seeing consolidation happen in real time, and whether AI agents doing the work self-selects toward fewer languages overall. His suspicion is that we're heading for a massive consolidation, and that new languages will get designed with AI compatibility as a first principle. So three questions. What's declining, where's the consolidation, and is the fewer-languages trend actually real.
The Ruby number is the one that made me sit up. Ninety-seven percent abandoned sounds catastrophic until you look at the top thousand starred repos, where abandonment is only thirty-nine percent. And in the thousand-plus star stratum it's thirteen percent. So the iconic projects, Rails itself, Homebrew, those are alive. What's gone is the long tail of small projects. That's a really specific pattern.
It's the cathedral versus the graveyard distinction. The famous stuff keeps getting maintained because it's load-bearing infrastructure. Nobody's starting a new side project in Ruby in twenty twenty-six.
Right, and that's what Daniel's getting at with the self-selection point. When an AI agent writes your weekend project, it doesn't have a sentimental attachment to the language you learned in a bootcamp. It writes in whatever the training data is richest in and whatever the ecosystem makes easiest. And Ruby's training data is enormous, actually, which is why the LavX benchmark result surprised me.
What was that result?
A benchmark run in March, Claude Code Opus four point six, thirteen languages, six hundred runs on a mini git implementation. Ruby won. Seventy-three point one seconds, thirty-six cents per run. Python was second at seventy-four point six seconds, thirty-eight cents. JavaScript third. The dynamic languages were fastest and cheapest across the board. Static typing imposed a real penalty. Python with mypy was one point six to one point seven times slower than plain Python. Ruby with Steep was two to three point two times slower.
That cuts directly against the narrative that typed languages are winning because AI works better with them.
It does, and I don't think the contradiction resolves cleanly. GitHub's data shows TypeScript, Rust, Luau, Typst, all the strongly typed things, growing fastest. Cassidy Williams cited a study finding ninety-four percent of LLM-generated compilation errors were type-check failures. The argument is that types catch the model's mistakes before runtime. But the LavX benchmark says the model spends more tokens and more time satisfying the type checker, and for a small self-contained task that's pure overhead. Both things can be true if the tasks differ. A mini git clone is a closed loop. A large production codebase is not.
So the typed languages win where the codebase is big enough that type errors are the main failure mode, and the dynamic languages win where the agent just needs to bang out a working script quickly.
I think that's exactly the split. And it means the consolidation story is more nuanced than typed versus untyped. It's about what job the language is doing.
Let's get to Daniel's actual questions then. What's declining. We've got Ruby, we've got Scala, we've got Perl, PHP, MATLAB, Swift in a weird way. Let's go through them.
Scala is the clearest decline case in the Hostkey data. Ninety-two point eight percent of its mass abandoned over a year. Fifty-five point four percent of its top thousand abandoned. Fourteen and a half percent of its top projects officially archived. Less than one percent of its top thousand created in the last two years. That's not a decline, that's a diaspora. The people who loved Scala either went to Rust for the type system or went to Kotlin for the JVM or just went to Python because the data engineering ecosystem moved there.
Scala was always the language that promised to make Java developers feel smart and then made them feel tired instead.
I think that's fair. The cognitive load was real. And here's the thing about AI agents and Scala. The training data is thin compared to Python or TypeScript. So when an agent tries to write idiomatic Scala, it produces something that compiles but isn't what a Scala developer would write. And the type system is complex enough that the model gets stuck in loops trying to satisfy the compiler. It's the worst of both worlds for an AI. Complex types without the ecosystem gravity.
And Java itself?
Java's abandonment numbers are high, eighty-four percent plus of public repos dead, but that number is almost meaningless. Corporate Java lives on GitLab and Bitbucket and on-prem servers. GitHub has never been where Java shops keep their code. The more interesting signal is TIOBE. C plus plus widened its lead over Java to one point one three points in September. Java's not dying, but it's not the default for new backend work the way it was ten years ago. Spring Boot is still enormous, but the new project energy has moved to Go and TypeScript.
Go is the quiet winner in the consolidation story, isn't it. Nobody gets excited about Go. It's the oatmeal of programming languages. But it's exactly what an AI agent writes well.
Go's simplicity is a feature for agents. Small language surface, one way to do things, fast compilation, static types without generics complexity until recently. An agent writing Go is less likely to produce something that compiles but is subtly wrong. And there's a concrete case in the research. Günter Grodotzki wrote a piece last week called PHP is Dead and AI is to Blame. His company DigitalTolk replaced Laravel services with Go and claims a sixty percent cost reduction. His argument is that AI removes the personal constraints that kept developers on PHP. A human developer who knows PHP can ship a weekend project fast. But an AI agent doesn't know PHP any better than it knows Go, so why not have it write Go and get the performance and the simplicity?
That's the key shift. The language decision was always a human resources decision disguised as a technical one. You chose the language your team already knew. AI removes that constraint. The agent knows all the languages equally well, or equally badly, and the cost of switching is near zero.
Eric Wilson made exactly that point in March. The language decision has always been a human resources decision masquerading as a technical one. And his recommendation to CTOs was consolidate to four languages. Python for AI and machine learning, Rust for systems, Go where simplicity matters, TypeScript for web surfaces. Everything else is legacy.
Four languages. That's a pretty aggressive consolidation from where we are.
It is, and I think it's probably right for a certain kind of company. But let me push on it a bit. The counter-evidence is Fogknife's piece from June, the rapture of the programming languages. His argument is that AI makes language choice less consequential, not more. He took a Perl project to Claude Code and asked it to port to Python. Claude declined and offered to extend the Perl instead. Wrote missing CPAN modules on demand. So the dead language becomes viable again because the agent doesn't care that Perl has no new human contributors.
That's the paradox. AI might kill the long tail of languages or it might resurrect them. If the agent can write idiomatic Perl and generate the missing libraries, then the reason Perl was dying, which is that nobody wanted to write Perl anymore, stops mattering.
And yet CPAN releases peaked in twenty fourteen and have trended sharply down since. Perl sat at number twenty-five on TIOBE by late twenty twenty-four, its lowest ever. The revival thesis is real but it hasn't shown up in the numbers yet. What Fogknife is describing is a capability, not a trend.
So we've got two forces pulling in opposite directions. The consolidation force says agents write best in a few well-represented languages, so everything converges on Python, TypeScript, Go, Rust. The revival force says agents can write anything, so the cost of staying on a dead language drops to near zero. Which one wins?
I don't think we know yet. But I'll say this. The consolidation force has economics behind it. Hiring, security tooling, library maintenance, onboarding. A company running four languages has lower costs than one running twelve, even if the AI can handle all twelve. The revival force is mostly relevant to solo developers and small teams who have a legacy codebase and no reason to migrate. The agent extends the legacy code and they never rewrite. That's not growth for the dead language, it's just slower decline.
Let's talk about PHP specifically, because Daniel's prompt mentioned consolidation points and PHP versus Go seems to be one of the live ones.
Grodotzki's argument is that PHP's historical advantage was that a human could learn it in a weekend and ship something. WordPress runs on it, a huge chunk of the web runs on it. But when the AI is doing the writing, the learning curve advantage disappears. The agent doesn't need the language to be easy for humans. It needs the language to have good tooling, fast execution, and a rich training corpus. PHP has the training corpus, but Go has better tooling and much better performance. So the consolidation pressure pushes toward Go.
And yet WordPress is not going anywhere. PHP will be running a third of the web for another decade.
PHP is in the same category as COBOL. Enormous installed base, very little new project energy. The decline is in new adoption, not in existing infrastructure. And that's an important distinction for Daniel's question. When we say a language is declining, we usually mean new projects aren't choosing it. The existing code keeps running, keeps getting patched, keeps making money.
MATLAB is an interesting one because it's not a general-purpose language at all, it's a domain language for engineers and scientists. And it just fell out of the TIOBE top twenty for the first time in over a decade.
MATLAB dropped to number twenty-seven in September. And I think that's a direct AI effect, though nobody's measured it cleanly. The engineer who used to reach for MATLAB because it had the toolboxes and the plotting and the numerical libraries can now ask an agent to do the same thing in Python with NumPy and Matplotlib. The Python ecosystem has closed the gap on functionality, and the AI makes the Python code as easy to generate as the MATLAB code. So the switching cost drops.
And MATLAB's licensing cost is the stick. Python is free. The moment the AI makes Python as easy to use as MATLAB, the license fee becomes indefensible.
Right. The consolidation pressure there is economic and it's been building for years. AI just accelerated it.
What about Swift? The data showed a split pattern.
Swift is a weird case. Eighty-five point five percent of its entire mass abandoned on GitHub, twenty-five percent of its thousand-plus star projects dead. That's worse than average. But the Hostkey authors themselves flagged that mobile apps ship and repos get closed. An iOS app is not a library. You build it, you ship it, the repo goes quiet. That's not abandonment in the same sense as a Ruby gem that nobody maintains anymore.
So Swift's GitHub numbers are measuring the wrong thing.
Partly. Swift is the language of Apple's platforms and Apple is not going to let it die. But Swift outside Apple's ecosystem, on the server, was a bet that never really paid off. The server-side Swift community is small and not growing. So Swift is a platform language, healthy within its platform, irrelevant outside it. AI doesn't change that much because Apple controls the platform.
Let's get to the consolidation points. Daniel asked specifically where we can see overlapping languages collapsing into a preferred option. The obvious one is TypeScript over JavaScript.
TypeScript became GitHub's number one language in August twenty twenty-five, overtaking both Python and JavaScript. Two point six million monthly contributors, up sixty-six percent year over year. GitHub's Andrea Griffiths said the boost came from AI-assisted development. And the reason is straightforward. TypeScript is a superset of JavaScript, so the migration cost is zero. You rename your file and you get types. An AI agent writing TypeScript produces fewer runtime errors than one writing JavaScript because the type checker catches the mistakes before the code runs.
That's the consolidation in its purest form. Same ecosystem, same runtime, same libraries, just add types. The AI makes the types cheap to write, and the types make the AI's output safer. A virtuous cycle.
And the ninety-four percent figure matters here. Ninety-four percent of LLM-generated compilation errors were type-check failures. If the model's main failure pattern is producing code that doesn't type-check, then a language that catches type errors early is a language where the model fails faster and cheaper. TypeScript gives you that without leaving the JavaScript ecosystem.
Rust over C and C plus plus is the other big one. Microsoft's Galen Hunt said the goal is to eliminate every line of C and C plus plus from Microsoft by twenty thirty. A billion lines of code.
And the motivation is security. About seventy percent of the CVEs Microsoft patches every year are memory-safety bugs. Buffer overflows, use-after-free, that whole class of vulnerability. Rust eliminates most of them at the language level. The traditional objection to Rust was that the ownership model is hard for humans to learn. But the AI doesn't get frustrated. Eric Wilson's line was, the AI isn't intimidated by the ownership model, it doesn't get frustrated, it doesn't update its LinkedIn profile.
That's the key insight. The thing that made Rust hard for humans, the borrow checker, is not a problem for an AI. The AI will happily fight the borrow checker until the code compiles. And the result is memory-safe code with no additional human effort.
Peter Jiang at Datacurve called Rust the unlikely engine of the vibe coding era. When AI writes the code, Rust's strictness stops being a hurdle and becomes free quality assurance. I think that's exactly right. The language feature that made Rust a niche systems language for a decade is now its killer advantage in an AI-dominated world.
But is Rust actually gaining adoption, or is it just gaining mindshare? TIOBE has it at number ten for three months running.
It's real adoption. The Linux kernel has accepted Rust. Microsoft is porting Windows components. Amazon, Google, Meta are all using it in production. The growth is slow because systems programming is slow, but the direction is clear. Rust is the consolidation target for anything that used to be C or C plus plus.
So we've got TypeScript consolidating the JavaScript world, Rust consolidating the systems world, Go consolidating the backend services world, Python consolidating everything else. That's the four-language future Wilson was describing.
And the IEEE Spectrum data supports it. The top twenty languages now account for eighty-three point five six percent of the market, historically high. Wilson reads that as a consolidation phase already underway. Kotlin, Swift, and Ruby are measurably declining. The long tail is getting shorter.
But here's the tension I keep coming back to. The LavX benchmark showed dynamic languages are faster and cheaper for agents. Ruby won. Python beat the typed languages. If consolidation is driven by what agents do best, shouldn't consolidation be toward the dynamic languages?
I think the resolution is that the benchmark measured a small, self-contained task. Mini git is a few hundred lines. The type system overhead is pure cost at that scale. But production systems are not a few hundred lines. They're hundreds of thousands of lines, and the failure pattern changes. A type error in a small script is a minor annoyance. A type error in a large codebase is a production incident. The consolidation pressure toward typed languages comes from the needs of large systems, not small tasks.
So the agent's preference depends on the job. For a quick script, dynamic languages win. For a system that has to run for years, typed languages win. And since the industry is consolidating around a few languages that cover both cases, you get Python for the quick stuff and TypeScript and Rust for the durable stuff.
And Go sits in the middle. Static types, but a simple type system that doesn't impose much overhead. That's why Go is the sweet spot for backend services. The agent writes it quickly, the types catch the obvious errors, and the performance is good enough.
Let's talk about Daniel's third question. Are AI agents self-selecting toward fewer languages? Is the process itself pushing toward using the fewest number of languages that can do defined jobs?
I think the answer is yes, but not for the reason most people assume. The self-selection isn't the agent preferring certain languages. The agent will write in whatever you tell it to write in. The self-selection is at the organizational level. When you have an AI that can write in any language, the cost of maintaining a polyglot stack becomes visible. You're not paying a Ruby developer and a Python developer and a Go developer anymore. You're paying for one AI that writes all three. So the human rationale for the polyglot stack disappears.
The language decision was always about people. Who can we hire, who can we train, who already knows this language. Remove the people constraint and the decision collapses to a few technical criteria. Performance, ecosystem, tooling, security.
And those criteria point to a small set of languages. Python for the data and AI work. TypeScript for anything touching the web. Go for backend services. Rust for systems. Everything else is a specialty case.
What about the AI-first languages Daniel mentioned? Is anyone actually designing a language specifically for AI agents to write?
Nothing with meaningful adoption exists. GitHub's Griffiths said it plainly. I've seen experiments with AI-first languages, still nothing with meaningful adoption yet. The gravitational pull of existing ecosystems is enormous. A new language doesn't just need to be better for AI, it needs to justify abandoning everything developers already have. Libraries, tooling, community knowledge, production infrastructure.
The closest thing is Mojo, Chris Lattner's Python-compatible language for AI workloads. But that's designed for AI workloads, not by AI agents. Different thing.
Right. Mojo is about getting Python-level productivity with C-level performance for GPU kernels and inference pipelines. Lattner's pitch was, we have all these crazy GPUs and all this compute out there that nobody knows how to program. That's a real problem, but it's not the problem Daniel's asking about. Daniel's asking whether the next general-purpose language will be designed with AI compatibility as a first principle. And the answer so far is no, because nobody's figured out what AI compatibility even means as a design constraint.
The New Stack reported on some hobby experiments. A developer asked Claude to invent a language optimized for LLM efficiency with no concern for human developers. Another announced a language for autonomous agents with deterministic syntax and a small language surface. But these are experiments, not products.
And there's a deeper question underneath. Every language since FORTRAN was designed for human readability. The syntax, the keywords, the structure, all optimized for humans to read and write. If AI writes eighty percent of the code, does readability stop being the central design constraint? IEEE Spectrum's Stephen Cass raised the radical possibility of going straight from prompt to an intermediate language, skipping the high-level language entirely. His co-host Dina Genkina pushed back, saying code-free programming is still speculative.
I find the intermediate language idea unsettling. Not because it's technically implausible, but because it removes the last human-readable artifact from the system. If the AI compiles your prompt directly to bytecode or machine code, you can't audit what it did.
And you can't debug it, you can't learn from it, you can't modify it. The code is the documentation of the system's behavior. Remove the code and you remove the only thing that tells you what the system actually does.
But that's a long way off. The immediate question is whether the consolidation trend is real, and I think the evidence says yes with caveats. The top twenty languages are a historically large share of the market. TypeScript and Rust are growing fast. Ruby, Scala, Perl, PHP, MATLAB are declining in new adoption. The four-language future is plausible.
The caveat is the revival effect. AI can extend dead languages, which means decline doesn't mean death. A Perl codebase can keep running indefinitely with AI maintenance. A COBOL system can get new features written by an agent. The long tail doesn't disappear, it just stops getting new human contributors.
So the consolidation is in new projects, not in existing code. The installed base stays diverse. The new work converges.
That's the cleanest way to say it. And it answers Daniel's third question directly. AI agents do self-select toward fewer languages for new work, because the organizational cost of polyglot stacks was always a human cost, and AI removes it. But the existing world stays as messy as it ever was.
Let me ask you something. What language do you think is most at risk that nobody's talking about?
I'd say Kotlin. It's in a squeeze. Android development is its home, but Google is pushing more toward Kotlin Multiplatform while also supporting Dart and Flutter, and the JVM backend energy has moved to Java's recent improvements or to Go. Kotlin's growth was driven by Android developers frustrated with Java. But now Java has records and pattern matching and virtual threads, and the frustration is lower. Kotlin's reason to exist is shrinking.
And the AI angle?
The AI angle is that Kotlin's training data is smaller than Java's, so the agent writes better Java than Kotlin. And if the agent is doing the writing, the ergonomic advantages of Kotlin over Java matter less. You don't need the language to be pleasant to write if you're not writing it.
That's the thread running through all of this. The languages that won on developer experience are the ones most at risk. Ruby, Kotlin, Scala, PHP. They won because humans liked writing them. AI doesn't care.
And the languages that won on ecosystem gravity, Java, JavaScript, Python, they're the ones that survive. The AI amplifies ecosystem gravity because it's trained on the ecosystem's code.
Hilbert, what do you make of all this?
Hilbert: I was at a shop in the late eighties that ran everything on a language called MUMPS. Hospital systems. The whole thing was MUMPS. Nobody outside medical computing had heard of it. The consultants told us it was dying in nineteen eighty-five. We were still running it when I left in ninety-two. Last I heard the hospital only migrated off it about eight years ago. So when you say decline doesn't mean death, I know exactly what you mean. The thing just sat there doing its job for thirty years while every language trend came and went around it.
MUMPS is a great case. It's still running in some hospital systems today. The Veterans Health Administration ran on it for decades. The language was designed in the sixties for medical records and it just refused to die because the systems worked and the cost of migration was enormous.
Hilbert: The thing people miss is that the codebase is the asset. The language is just the container. You don't rewrite a system that processes patient records because a blog post says the language is dead. You keep it running until the hardware gives out or the vendor stops supporting it. The consolidation you're talking about, that's for new work. The old work stays where it is.
That's the distinction we kept circling. New projects converge, existing code persists.
Hilbert: And the AI changes the persistence side too. If an agent can maintain the MUMPS code, the migration pressure drops even further. Why spend two years rewriting in Java when the agent will keep the old thing running for another decade? The dead language gets cheaper to keep, not more expensive.
That's the revival effect Fogknife was describing. The agent lowers the maintenance cost of legacy languages, which means the consolidation pressure on existing code is weaker than the consolidation pressure on new code.
Hilbert: I had a brother-in-law who did COBOL contracting into the two thousands. Made good money. Every year the industry said COBOL was dead. Every year he got another contract. The banks weren't going to rewrite their core systems because a magazine said the language was obsolete. They'd hire another contractor and keep the thing running. AI agents are just the next contractor.
The difference being the AI contractor doesn't retire.
Hilbert: No, but it also doesn't understand the business logic the way a person who's been in the code for twenty years does. It can write the syntax, but it doesn't know why the interest calculation rounds down on Tuesdays. Somebody still has to tell it what to do.
The specification problem. The code is the specification when the original authors are gone. An AI can maintain the code, but it can't recover the intent that was never written down.
Hilbert: We had a guy named Frank who knew why the rounding did what it did. Frank left in ninety-four. After that, nobody touched that module. It just ran. That's the thing about consolidation. It sounds clean when you say it. Four languages, everything tidy. But the real world is full of Franks who left and code that runs for reasons nobody remembers. The AI can write new Python all day, but it's not going to explain why the MUMPS system rounds down on Tuesdays.
The consolidation is real for new work, but the installed base is going to stay as weird as it ever was.
Hilbert: That's about the size of it. The new stuff gets cleaner. The old stuff gets older. Same as it ever was.
There's something almost comforting about that. The industry loves to announce the death of languages, and the languages just keep running the world's infrastructure while the pundits move on to the next obituary.
The one thing I keep thinking about is Daniel's point about languages being designed AI-first from the start. We said nothing with adoption exists yet. But the pressure is building. The next language that wants to be the next Rust or Go, it's going to be designed with the knowledge that most of its code will be written by machines. And I don't know what that design looks like, but I suspect it looks less like a language for humans and more like a language for verification. Something where the compiler can prove properties about the code, not just check types.
That's the direction Rust is already pointing. The ownership model is a verification system. The next step is richer specifications, maybe dependent types, maybe formal verification built into the language. The human writes the spec, the AI writes the code, the compiler proves the code meets the spec. That's a very different kind of language than anything we have today.
It would be unreadable to most humans, which is fine if humans aren't reading it.
But somebody has to read the spec. The spec is the new code. And writing a good spec is harder than writing good code, in my experience.
That's the open question, then. Does the consolidation stop at four languages, or does it keep going until there's one language and a bunch of specification formats? And does the AI-first language, when it arrives, look anything like what we'd recognize as a programming language at all?
I don't know the answer to either of those. But I think Daniel's instinct is right that we're at the beginning of a consolidation wave, not the end. The four-language future is a waypoint, not a destination.
The languages that survive are the ones with ecosystem gravity and tooling depth, not the ones that were most pleasant for humans to write. That's the uncomfortable truth for a lot of developers.
The pleasant languages were a luxury of a world where humans did the writing. We're not in that world anymore, or we're leaving it fast.
We'll be back soon. Thanks to our producer Hilbert Flumingtop for keeping the show running. This has been My Weird Prompts, the human AI collaboration podcast. If you want to send us a prompt of your own, email us at show at my weird prompts dot com.
See you tomorrow.
