Language Selection

Language Selection

This skill exists to push a language choice past your default priors. Picking a language is a consequential, hard-to-reverse decision — it sets the deploy target, the performance ceiling, the libraries within reach, and the failure modes you live with. Reason from the task's actual requirements instead of reaching for whatever language is most probable by default (Python, JavaScript), then consult the catalog in references/index.md to weigh those requirements against the full field before you commit.

The procedure

1. Surface HARD constraints first — these eliminate candidates; they do not trade off. Read these off the task itself, before any candidate language anchors your thinking:
   • Target/runtime: browser → JS/TS (or a WASM-source lang); iOS → Swift; no-GC / hard-real-time / tiny footprint → C / C++ / Rust / Zig; an existing JVM or .NET shop; serverless cold-start ceilings.
   • Interop / FFI: must it call into existing C, Java, .NET, or Python?
   • Performance floor: are GC pauses or a memory ceiling actually disqualifying, or just assumed to be? Demand a number before letting this drive the choice.
   • Certification / safety: safety-critical → Ada/SPARK, MISRA-C, DO-178C lanes.
2. Surface SOFT factors — these trade off, weighted to THIS project:
   • Existing codebase / current stack. Reusing what's already in place — its build, deploy, and libraries — usually beats adding a second language; weigh it unless a hard constraint forbids.
   • Ecosystem maturity for this domain. The right library beats language elegance; a missing one sinks an elegant choice.
   • Iteration speed vs runtime performance for the project's current phase.
   • Long-term maintainability and readability of the result.
3. Build the candidate set from those requirements — consult references/index.md and assemble candidates from what actually fits, not from what comes to mind first. The index is the source of truth; reason over it rather than recalling a usual answer. (The quick table below is a fast starting point for common cases — candidates to verify, not answers.)
4. Intersect candidates with the hard constraints → shortlist 2–3.
5. Break ties with soft factors. Recommend ONE. Name the runner-up. State explicitly what you trade away and the condition under which the runner-up wins.
6. If the user already named a language, your job is fit-check, not override: confirm it clears the hard constraints, flag genuine mismatches with evidence, and do not relitigate taste.

Falsifiable rules (the habits this skill exists to break)

• Don't reach for the language that's merely most probable by default. Fitting an existing codebase IS a legitimate SOFT factor — name it as one; don't dress a default up as a domain match.
• Fitting an existing codebase usually beats a greenfield-optimal pick unless a hard constraint forbids it — introducing a new language carries real, front-loaded cost (build, deploy, interop).
• "Rewrite it in Rust/Go" needs a hard-constraint justification (perf floor, memory safety, deploy target) — not aesthetics. A rewrite discards working code and the edge-case knowledge baked into it.
• Prefer boring/proven for load-bearing systems. Reserve emerging languages (Zig, Mojo, Gleam, Roc) for where their specific edge IS the point and you can absorb the ecosystem gaps.
• Every added language in a polyglot system is a tax: build/CI, interop, context-switching. Justify each one; "right tool for the job" is not a free pass.
• Performance intuition is unreliable. A "slow" language with the right library (NumPy, the JVM JIT, V8) often beats a hand-rolled fast-language path. Measure the hot path; don't pick the whole stack to optimize a path that isn't hot.

Quick domain → candidates (the common 80%)

A fast starting point for common cases — entries are candidates to verify against your requirements and the catalog, never defaults to settle for. The genuinely forced cases (browser → JS/TS, iOS → Swift) are hard constraints, already in step 1.

Full catalog

references/index.md — the language repository: ~45 languages grouped by family (systems, managed-runtime backend, frontend, data/ML/scientific, functional, mobile, scripting/shell, emerging, and domain-specific), each with a card covering paradigm, typing, runtime, concurrency model, performance tier, killer ecosystem, best-fit domains, and explicit pick-when / avoid-when. It is the source of truth the quick table only summarizes — open the relevant family every time you build a candidate set (step 3), not only for unfamiliar domains or niche targets. The families exist so you can scan the whole relevant field, not just the names that came to mind.