Language Selection
Pick the programming language based on the problem shape, team expertise, and ecosystem — not fashion.
Why
Language choice is sticky — you'll write 100k lines in it and hire for it for a decade. The right language makes the problem easy (Rust for systems, Python for ML, Go for services, TypeScript for web) and the wrong one makes it hard (Python for a real-time OS kernel, Rust for a data notebook). The decision should be driven by the problem shape (what the language is good at), team expertise (what you can hire and review), and ecosystem (the libraries that exist) — in that order. Choosing by fashion ('everyone uses Rust now') gets you a language that's technically capable and operationally painful because no one on the team can review it.
When
At the start of a new service or component. Takes 1-2 hours for the decision (days if a prototype is needed). Revisit rarely — switching is expensive.
How
1. Characterize the problem: CPU-bound? IO-bound? latency-critical? batch? needs ML? needs systems-level control? 2. List candidate languages that fit the problem shape: - Services (IO-bound, concurrent): Go, Java, Python, Node - Systems (CPU, memory control): Rust, C++, C - ML/data: Python, R, Julia - Web frontend: TypeScript (only real choice) - Glue/scripts: Python, Bash 3. Filter by team expertise: can we hire, review, and on-call for this language? 4. Filter by ecosystem: do the libraries we need exist and are they maintained? 5. If 2+ remain, prototype the riskiest part in each (1 day each) and compare 6. Decide; document the reasoning (problem shape + expertise + ecosystem) in an ADR 7. Resist re-litigating — language churn is more expensive than any single language's flaws
Example
Service: real-time price aggregator (CPU-bound, latency-critical, <10ms p99) Candidates by problem shape: Go, Rust, Java, C++ Filter by team expertise: team knows Go + Python, no Rust/C++ reviewers Filter by ecosystem: Go has good financial libs; Java has more but heavier Prototype: write the hottest path (order book merge) in Go and Java - Go: 3ms p99, 200 lines, easy to review - Java: 2.5ms p99, 250 lines, GC tuning needed Decision: Go. Reasoning: fits problem, team can review + on-call, ecosystem sufficient. Rust would be faster but we can't review it safely.
Common Problems
- ⚠Choosing the newest language for a service team — novelty is fun, but a service in a language no one on-call knows is an incident waiting to happen.
Best Practices
- ✓Default to the team's strongest language unless the problem shape clearly demands otherwise — productivity and reviewability beat theoretical performance.
- ✓Allow at most 2-3 languages in production per team — polyglot is expensive (tooling, hiring, on-call); the benefits of the 4th language never pay off.