I’m on holiday this week, so please enjoy this one from the vault: my most controversial piece ever, by a long margin. “Apple is Killing Swift”. Learn how programming languages are governed, why Swift’s problems today are a natural consequence of governance, and whether there is any hope for its future.
Swift was a great language, but it has fallen far from its original vision.
Pretty damn far.
First; a quick history lesson.
Swift was the evenings-and-weekends passion project of Chris Lattner, creator of LLVM and senior director of dev tooling at Apple. Senior leadership team was jammed to the gills with the OG NeXT crew, on first-name terms with Jobs, who built their careers on Objective-C. It took a lot of internal politicking to get Swift the green-light.
In classic Apple secrecy, prior to the WWDC 2014 announcement, only 250 internal employees even knew about the project that would eventually obsolete millions of codebases.
Lattner’s vision?
Simple things that compose.
Progressive disclosure.
One way to do things.
Prior to the announcement, Chris and the Objective-C team had been playing a long game of 3D chess by quietly introducing Swift compatibility features like modules, automatic reference counting, and nullability across core frameworks.
In 2015, Lattner achieved the unthinkable: convincing the world’s second-most secretive company to open-source Swift. Thus Swift evolved driven by 3 tribes who kept each other in check:
Lattner himself, driving his core vision and keeping a lid on tech debt.
The open-source community, who fundamentally want what’s best for the language, but in aggregate behave like a trash bag full of cats.
Apple, the behemoth that pays the Swift team’s salaries, which has an unwavering commitment to profit.
In 2017, Chris buggered off to mess around with AI. Tim Cook’s MBA buddies began to wriggle their tendrils into Swift and guide it towards its next life stage.
“Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…”
— Chris Lattner, 2024
Today in 2026, we are... well. 217 keywords. Not simple. No composey.
Without Lattner’s iron fist, Swift sits uncomfortably at a pinch-point between two opposing clans: the open-source community™, and Apple Incˢᵘᵖᵉʳ™.
They both wage their own wars, with their own incentives, and their own imperfections. Guess who holds all the cards.
“Apple Inc. is the project lead and serves as the arbiter for the project. The project lead makes senior appointments to leadership.”
Subscribe to Jacob’s Tech Tavern for free to join 100,000 Swift devs learning advanced concurrency, agentic iOS engineering, and Swift performance for 10 minutes a week.
How to Govern a Programming Language
All languages are maintained by an individual, a team at a company, or a large distributed community. Owners set rules for how changes, features, & extensions are selected, designed, & implemented. This is critical for a sense of stability, continuity, and improvement, and critically to maintain backwards-compatibility. Developers like to know their livelihood isn’t getting deprecated.
How do the greats do it?
Python: Benevolent Dictator For Life
Python was created by Guido van Rossum in 1990, who was named the the BDFL (benevolent dictator for life), a title which is both rad as hell and basically a euphemism for “lead maintainer”). Ultimately, the fiery debate over assignment expressions led to Guido’s abdication in 2018.
Today, Python is governed by a steerco of 5 elected engineers, picked by the 100-odd open-source maintainers. Changes are proposed by PEPs and deliberated.
“Python makes slow and careful steps towards new features and versions.”
— Guido van Rossum
Rust: Community-driven open-source
Rust was created by Graydon Hoare and adopted by Mozilla, eventually picked up by the Rust Foundation (funded by AWS, Huawei, Google, Microsoft, and all their friends). Changes to the Rust language are discussed viaRFC, steered by teams focused on language,compiler, and dev tools. While this might sound utopian, the Rust community, like all open-source communities, is not without its drama.
“Everyone is invited to discuss the proposal, to work toward a shared understanding of tradeoffs. Though sometimes arduous, this community deliberation is Rust’s secret sauce for quality.”
— Rust Governance
Kotlin: Corporate-backed open-source
Kotlin was created by JetBrains, the IDE company, in 2011, who hoped to sell more copies of IntelliJ and cross-sell other dev tools. In a huge coup, Google announced Kotlin support for Android in 2017.Kotlin is governed by the Kotlin Foundation, i.e. Google & JetBrains. The board appoints the lead designer, basically a high-ranked JetBrains dev. The community submits KEEPs and devs play with experimental APIs before release.
“Language design is cast in stone,
but this stone is reasonably soft,
and with some effort we can reshape it later.”
— Kotlin Design Team
Major languages have an open-source community which proposes and deliberates changes. They also have a centralised faction that has the final say on code changes.
Incentives
Fundamentally, language governance is about aligning incentives. Each has 3 major constituencies:
End-user devs who use the language day-to-day.
The community submitting language proposals.
The steering group with the final say.
End-user devs want a nice language, and vote with their keyboards. Often in the millions, this cohort ultimately has the least sway because language switching costs equal years of experience.
The community includes the most passionate end-users and usually full-timers in the pocket of the steering group. They often have pure incentives: make a good language. But also, other forces are in play:
Résumé-driven-development. I want to be the guy who implemented Borrowing because it makes me look attractive to employers.
Bikeshedding embodies the path of least resistance: devs love to focus on trivia like syntax and naming. Hey, they still helped.
The steering group is the most powerful by far. Their incentives depend entirely on governance structure:
Python and Rust steerco contains the most dedicated community members, nudging imperfect sets of incentives into something vaguely resembling “what’s good for the language”.
With Kotlin, Jetbrains and Google have a clear profit motive. Fortunately, selling IDEs and making Android devs productive align pretty well with end user devs.