Choosing a language

Deep dive

Decision table

Cost model

Numbers are order-of-magnitude for CPU-bound code; I/O-bound services see much smaller gaps.

How to decide

1. List the hardest technical requirement (p99 < 1 ms? GPU kernels? 1M websockets? iOS?). It usually eliminates most options.
2. Check the ecosystem: is there a mature library for your database, protocol, cloud SDK, auth provider?
3. Weigh the team: a language nobody on the team knows costs months; hiring markets differ by region.
4. Prototype the hot path and measure before committing to a "fast" language for everything.
5. Plan the boundary for mixing: FFI (C ABI), WASM, gRPC between services, or a GPU language under Python.

Code

A typical split: Python orchestration calling a Rust hot loop through PyO3/maturin.

// Cargo.toml: [lib] name = "fastlib", crate-type = ["cdylib"]; pyo3 = { version = "0.22", features = ["extension-module"] }
use pyo3::prelude::*;

/// Count positions where two equal-length byte strings differ (hot loop in Rust).
#[pyfunction]
fn hamming(a: &[u8], b: &[u8]) -> PyResult<usize> {
    if a.len() != b.len() {
        return Err(pyo3::exceptions::PyValueError::new_err("length mismatch"));
    }
    Ok(a.iter().zip(b).filter(|(x, y)| x != y).count())
}

#[pymodule]
fn fastlib(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(hamming, m)?)?;
    Ok(())
}

uv tool run maturin develop --release   # builds and installs into the active venv
python -c "import fastlib; print(fastlib.hamming(b'abc', b'abd'))"

Efficiency

• Cost: per-language costs are on each language page; the ones that decide a choice, with their sources: a goroutine starts with a few KB of stack (Go FAQ), an Erlang process uses 327 words, about 2.6 KB (Erlang Efficiency Guide), a CPython int is 28 bytes (measured with sys.getsizeof), Spring PetClinic starts in 4.5 s on JDK 23 and 2.6 s with an AOT cache on JDK 24 (JEP 483), and Wasm ran SPEC CPU 45-55 % slower than native in browsers (Jangda et al., 2019). Bound: usually the database and network, not the language.
• Levers:
  • profile, then move only the hot function to a faster language — one loop is usually the problem (order of) — Python or JS services with one hot spot
  • batch calls across the language boundary — one call per buffer, not per element (no figure) — PyO3, N-API, Wasm and cgo boundaries
  • ahead-of-time compile for startup (JVM AOT cache, Native AOT, Wasm precompile) — 42 % lower startup on PetClinic (JEP 483) — serverless and CLIs
  • tune the GC instead of leaving it (GOGC, ZGC, MaxRAMPercentage) — halve GC CPU or cut pauses (Go GC guide, JEP 439) — GC'd services with a latency or memory target
  • keep to two to four languages per organization — fewer toolchains to secure and staff (order of) — whole-org decisions
• Naive → standard → state of the art:
  • rewrite everything in the fastest language · months of work, gain only if CPU-bound
  • profile, then fix the query or loop in the current language · usually enough
  • current language plus a native hot path behind a stable ABI (PyO3, napi-rs, UniFFI) · native speed where it matters

Pitfalls

• Choosing by benchmark-game numbers for an I/O-bound CRUD service.
• Choosing by hype for a team that can't support it in production (on-call, debugging, profiling).
• Rewriting a working system for speed without profiling; usually one query or one loop is the problem.
• Too many languages in one org: each adds CI, security scanning, libraries and hiring overhead. Two to four is plenty.
• Ignoring deployment: GC'd runtimes in small containers, JIT warmup in serverless, Python native wheels on unusual platforms.
• Using dynamic languages for large codebases without type checking (mypy/pyright, TypeScript strict).

Implementations

Sources

• Gouy, The Computer Language Benchmarks Game. site
• Pereira et al., Energy Efficiency across Programming Languages, SLE 2017. paper
• TechEmpower, Web Framework Benchmarks. site
• Per-language sources are linked on Go, Rust, Python, Java/Kotlin, C#, Erlang/Elixir and WebAssembly.