Why engineers can't be rational about programming languages

Scope of the debate

• Several commenters note many responses fixate on “rewrites” instead of the article’s main claim: engineers’ language choices are strongly driven by identity and emotion, then rationalized after the fact.
• Others push back on the charged title, saying they’ve seen plenty of rational, pragmatic language decisions, and that the article overgeneralizes from a few anecdotes.

How important is language choice, economically?

• The claim that “a programming language is the single most expensive choice a company makes” is widely disputed.
• Many argue leadership quality, team composition, architecture, and infrastructure decisions dwarf language choice in impact.
• Some concede language can be costly at the extremes (e.g., dead ecosystems, very mismatched performance needs, exotic databases), but say most mainstream languages are “good enough” for typical business software.
• A minority argue tool choice can indeed make or break some projects (e.g., high‑performance DBs, real‑time systems), and treating language as interchangeable is itself bad engineering.

Rewrites and migrations

• Strong consensus: rewriting solely to change language is usually a terrible idea; only justified when the platform/ecosystem is clearly dead, fundamentally wrong for the domain, or non‑maintainable.
• Success stories exist but are treated as rare, special‑circumstance exceptions, often done incrementally.
• Many emphasize that rewrites mostly re-learn hard‑won lessons and risk years of delay.

Identity, tribalism, and cognitive bias

• Many endorse the article’s idea that language allegiance is tied to professional identity and fragile expertise; unfamiliar languages temporarily make people feel less competent.
• Others liken languages and their communities to cults with charismatic leaders, dogma, aesthetics, and “holy texts.”
• There’s discussion of Dunning–Kruger and emotional reasoning, but also criticism that the article pathologizes disagreement without rigorously proving its claims.

Who should choose, and based on what?

• Tension between:
  • “Use what the team already knows” / minimize cognitive and hiring cost.
  • “Pick the right tool for the job” / avoid forcing everything into one stack.
• Several note management often drives hype‑based choices (Rust, React, Rails, etc.), or imports biases from peers (“language X doesn’t scale”).
• Some stress the real failure is hiring “language technicians” instead of language‑agnostic engineers who can move across stacks and treat tools instrumentally.