You've been in this meeting, right?
Every new project starts with the same ritual: picking the stack. Requirements and architecture get all the attention, but "what do we build this with?" matters just as much.
So your team debates it properly. You weigh the options, land on a choice, and everyone agrees: "Yeah, this is the right fit for us." Then you present it in a review meeting, and someone — a manager, a stakeholder, an architect from another team — asks:
"Why did you choose this language?"
"Would another language not have worked?"
If reading that made your stomach drop a little, keep scrolling. 😅
Here's the thing I wish someone had told me earlier: this question is not an attack, and it's not someone doubting your skills. What the asker actually wants to know is much simpler:
"Is this decision sound from a business perspective?"
Let me put one disclaimer up front:
There is no absolute ranking of programming languages.
This is not a "language X is better than language Y" post. But every language that survives has reasons it keeps getting chosen — and whether you can articulate those reasons out loud is the entire game.
I've been asked this question many times across my career. For years I answered with technical merits, and every time I got the same politely unconvinced face. Eventually it clicked: what's really being tested isn't "is it the most modern?" or "is it the fastest?" It's:
"Can you explain this choice to a third party, in business terms?"
That's what this post is about. By the end, I hope you'll feel ready to walk into your next review and defend your stack with confidence.
What decision-makers are actually evaluating
When engineers talk tech selection, we gravitate toward performance, modernity, and trends. Those matter. But the people approving your proposal are usually worried about something far more mundane — and far more long-term:
- Can we hire and hand over this codebase years from now?
- Can we maintain it without heroics in year three?
- Will it survive spec changes and reorgs?
- Does the cost actually pay off?
- Does the project depend on one irreplaceable person?
Looking back at projects I've been on, these are exactly the things nobody worried about at kickoff — and everything that quietly hurt later.
A language with a steep learning curve slows down every onboarding. A team of three can absorb that; a team of fifteen can't. And a niche technology means one resignation can destabilize an entire project.
Which leads me to the definition I now use:
Tech selection isn't picking the best option for this moment. It's making a choice you could re-explain to your future self in three years — and still nod at.
"This language is trending and I want to try it" is a fine reason to start a side project. It's a terrible reason to bet a product on.
Languages that keep getting chosen have reasons
Across the languages that survive decades in production, the same traits show up:
- Easy to learn — new members become productive fast
- Easy to build with — you spend time on the actual problem
- Easy to operate — the thing stays maintainable after launch
(Plus domain-specific strengths: easy to build securely, easy to squeeze hardware performance, and so on.)
In an industry this trend-driven, anything still standing after 20 years is not standing out of inertia.
I spent the longest stretch of my career in PHP shops, so here's an example from that world: WordPress and MediaWiki (the software behind Wikipedia) are PHP. What they share isn't elegance — it's that they've been continuously maintained for decades. A language's longevity directly becomes the longevity of the products built on it.
And this isn't a PHP thing. Python's machine-learning ecosystem, TypeScript's grip on frontend, Go's dominance in cloud-native infrastructure — each has clear, articulable reasons it keeps being chosen.
What matters is whether you can explain, in your own words, why your language keeps being chosen.
The 4 lenses of defensible tech selection
Here are four lenses that work regardless of language. If you can answer "why this language?" along these four axes, you'll convince most rooms.
Lens 1: Talent depth — can you avoid a bus factor of one?
The most overlooked question in tech selection: how many people in the market can write this?
A language with a large developer population gives you options — for hiring, for mid-project reinforcements, for handovers. Choose something niche and you've signed up for "if this person leaves, we're stuck."
For example:
- Python — huge population across data science and web; lots of career-changers learning it, so the hiring funnel is wide
- TypeScript — effectively the lingua franca of frontend; JavaScript developers convert easily
- Go — growing fast among infra-leaning engineers, though the pool for business-app web development is still thin in some markets
Choose with "can the team keep shipping?" in mind, not "do I love this language?". It's unglamorous, and it's the foundation everything else stands on.
Lens 2: Fit for purpose — is this the shortest path?
Every language has home turf. Yes, most modern languages can technically do anything — but whether they get you to your goal by the shortest path has a huge impact on productivity.
"I just want to write business logic, but my week is disappearing into environment setup and plumbing..."
Sound familiar?
- Building a web application? Pick a language whose ecosystem naturally speaks HTTP, sessions, and templating
- Data processing / analytics? Very little competes with Python's ecosystem (pandas, NumPy, ...)
- High-throughput API servers? Go's concurrency model earns its keep
- One type-safe language across frontend and backend? That's the realistic case for TypeScript
If you can say "this language is specialized for — or at least strongly aligned with — what we're building", your proposal gets dramatically more persuasive.
Lens 3: Ecosystem maturity — will you reinvent wheels?
Modern development runs on frameworks and libraries. Auth, validation, email, background jobs — whether these come ready out of the box directly determines your velocity.
- Python — Django, FastAPI. Django's "batteries included" philosophy ships an admin UI, ORM, and more from day one
- TypeScript — Next.js, NestJS. The full-stack-in-one-language ecosystem has genuinely matured
- Go — an excellent standard library; you can go far without a framework, but business-app "we also need this and this and this" features often end up hand-rolled
And here's the part people miss: ecosystem maturity isn't just about building fast.
It's about surviving change.
With a mature framework, a spec change means a small adjustment, not a rewrite. That's what lets a team keep moving without flinching.
Lens 4: Cost and operations — can you keep this running?
The final piece is total cost — not just infrastructure, but operations, incident response, and salaries. Think ROI, not hosting bill.
- Does it need a special runtime or environment?
- Does it run on a simple infrastructure setup?
- Can you start small and scale later?
Being able to say "we can start cheap, and it holds up if we grow" carries enormous weight with business decision-makers. It's not flashy — but for anything meant to run for years, "sustainable without heroics" is priceless.
The inevitable question: "But is it fast enough?"
Whenever languages get compared, this one shows up. And yes — some languages extract more from the CPU than others.
But look at where most web applications actually spend their time:
- Database access
- External API calls
- Network latency
The raw execution-speed gap between languages is the bottleneck far less often than people assume.
Of course, if you're building real-time systems or handling massive concurrent connections, the calculus changes. But for most business systems and web services, architecture and query optimization move the needle far more than language benchmarks ever will.
The mature answer isn't "this language is fast" — it's: "For these requirements, is language performance actually going to be the bottleneck?" Usually, it isn't.
When you're asked to compare — compare like this
"How does it stack up against language X?" is unavoidable. The goal is not to win a technology debate. It's to explain the lowest-risk business choice.
Here's my rough mental cheat sheet for commonly compared languages:
| Language | Strength | Watch out for |
|---|---|---|
| Python | Low learning curve, unmatched in AI/data | Large-scale web apps need deliberate architecture |
| Go | High performance, great concurrency | Business web apps mean hand-rolling things frameworks give you elsewhere |
| TypeScript | One language across the stack, type safety | Fast-moving ecosystem; dependency management needs discipline |
| Rust | Safety and performance | Steep learning curve, harder hiring |
(Disagreements welcome in the comments 😄 — this is my experience, not a benchmark.)
No language is perfect. Which is exactly why the winning move is explaining "given our constraints, this is the best fit" — from the listener's point of view.
The ready-to-use script
"Okay, I get the theory. What do I actually say?" Here's a template you can deliver calmly in one to two minutes:
For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.
[Language] has [track record / market share], including long-running production systems like [concrete product examples].
We chose it because the large developer population keeps hiring and handover risk low, and because it specializes in [the language's home turf], giving us a good balance of learnability, implementation speed, and maintainability.
We did evaluate alternatives, but for these requirements, [language] was the lowest-risk choice in terms of speed, cost, and continuity.
Example: making the case for Go
For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.
Go is widely adopted across the cloud-native landscape — Kubernetes and Docker are written in it — with a strong track record of long-running production systems.
We chose it because its simple language design keeps code consistent across engineers, and its concurrency performance matches the requirements of our API platform.
We also evaluated Python and TypeScript, but for these requirements, Go was the lowest-risk choice in terms of speed, cost, and continuity.
Notice the framing: not "we picked the most impressive option" but "we picked the lowest-risk option." Decision-makers relax at the second one, not the first.
And there's a bonus effect: even if the answer is still "no," a structured explanation like this makes it obvious which specific concern is blocking approval — so your second attempt becomes a targeted fix instead of another shot in the dark.
Tech selection is accountability to your future self
If I had to compress this whole post into one line:
Tech selection isn't choosing what's most impressive today. It's making a decision you can still explain — and stand behind — years later.
You've probably heard (or been the subject of) the line: "They can build things, sure, but they never think about operations." I've been on the receiving end of that one. It stings because it's fair: being right today isn't enough.
And if you're drawn to a language because it's trending or because you want to learn it — protect that curiosity, it's what keeps this job fun — but on its own, it won't get a proposal approved. Pair it with a business case built on the four lenses:
- ✅ Deep talent pool — low bus-factor risk
- ✅ Fit for purpose — shortest path to the goal
- ✅ Mature ecosystem — no wheel reinvention
- ✅ Realistic cost and operations — sustainable for years
Cover those four, and you can propose any language with your head held high.
Now go pitch your stack.
This article is an English adaptation of a piece I originally wrote for the pamphlet of PHPerKaigi 2026, a Japanese PHP conference, later reworked for Qiita (Japanese).
Top comments (0)