All posts
30 JULY 2023 · · 5 MIN

Which language should I learn? The question beneath the question

Which language should I learn? The question beneath the question
When someone asks which programming language they should learn, the honest first move is to not answer the question yet. Ask them what they want to build. For most of the last decade, the joke has been that the answer is JavaScript regardless - Web: JavaScript, Mobile: JavaScript, Backend: JavaScript, Desktop: JavaScript. The joke works because JavaScript has genuinely colonised more domains than any language in computing history. It also fails in specific places, and the places where it fails are where the interesting careers live.

The reason the question needs reframing is that 'which language' is almost never what the asker actually wants to know. Usually they're asking 'how do I become a programmer' or 'how do I get a job in tech' or 'how should I invest the next two years of learning time'. Answering the surface question with a language name skips the more important layer. Once the domain is clear, the language choice often becomes obvious and sometimes becomes irrelevant.

Where JavaScript actually wins

For anyone wanting to build web applications, the honest answer is still JavaScript or TypeScript plus some familiarity with HTML and CSS. The ecosystem, the jobs market, the learning resources, and the example code are all overwhelmingly web-JavaScript. Backend JavaScript via Node is a coherent choice for full-stack work. React Native extends it to mobile, if imperfectly. Electron extends it to desktop, with well-known costs. For someone who will spend the next three years making websites or web apps, JavaScript is the right investment, and the joke about JavaScript-for-everything reflects this accurately.

Where the joke misleads is in suggesting that JavaScript is the right answer for every domain. It isn't. For game programming at professional level, the real answers are C++ and C#, because the engines (Unreal, Unity) and the performance requirements both demand them. For systems programming, embedded, operating-system work, or anything performance-critical, C, Rust, or Zig remain the only credible options. JavaScript in these domains is either absent or a second-class citizen with serious operational costs. The joke works because JavaScript has swallowed so much that the remaining territory can feel marginal, but the remaining territory is larger and more important than the punchline suggests.

AI as its own case

For anyone whose target domain is AI - building models, deploying them, training, research - Python dominates and isn't close to being displaced. TensorFlow.js exists. LangChain has JavaScript bindings. These are real. The books, the courses, the research code, the jobs, and the ecosystem are overwhelmingly Python. An AI learner starting with JavaScript will spend the first year translating everything and falling behind people who took the conventional route. The joke breaks here. Python is the honest first answer for AI work, and only Python.

The nuance worth adding is that modern AI development splits into several roles, and not all of them are Python-first. If the goal is to train models or do ML research, Python is the answer. If the goal is to build products on top of existing models via API - chatbots, agents, retrieval-augmented applications - any general-purpose language works, and TypeScript is as reasonable as Python. If the goal is to do infrastructure for AI systems at scale - serving, routing, observability - Go and Rust become important. The domain of 'AI' is large enough that the language question has several valid answers depending on which role within AI you're actually targeting.

The hardware and embedded case

For anyone interested in hardware, robotics, embedded systems, or IoT, JavaScript is emphatically not the answer. The honest first language is still C - not beautiful, not fashionable, still the right answer. Half of the IoT industry runs on C codebases that are expected to run for a decade with minimal updates. Rust is gaining ground for new work. C++ continues to dominate where existing codebases demand it. Anyone learning for these domains who follows the 'JavaScript for everything' advice will spend years catching up later. Worth being specific when the asker cares about the silicon side of the industry.

The second-language question

The advice that's worn best over time is that the second language you learn matters more than the first. The first language teaches syntax. The second language teaches that languages have opinions - memory models, type systems, concurrency primitives, execution models - and that these opinions shape what code is natural to write. Programmers who know only one language deeply don't see the constraints they're operating under. Programmers who know two or three see the shape of their own assumptions and can reason about when to break out of them.

For someone who started with JavaScript or Python, the second-language options that produce the largest perspective gains are typically Rust (ownership and type rigour), Go (concurrency and simplicity), Haskell (pure functional constraints), or C (manual memory management). None of these are necessarily productive for your day job. All of them will make you a measurably better programmer in your primary language. The learning investment pays off over a career, not over a quarter.

The first language teaches syntax. The second language teaches that languages have opinions.

The 2026 update

The AI coding tools of the last two years have changed the calculus meaningfully. Picking up a second language now, with copilot assistance, is materially faster than it was pre-2024. A competent programmer can be productive in a new language within a month of focused work, not the six to twelve months it used to take. This reshapes the traditional 'learn one language deeply' advice - the faster you can add languages, the less high-stakes the first choice becomes. You can optimise for domain fit today, knowing you can broaden cheaply later.

The updated advice is therefore: pick the language closest to your domain first, go deep for a year or two, then add a second language with copilot assistance when the domain demands it. This is faster than 'pick one language for your whole career' and more effective than 'learn five languages superficially'. The combination of deep primary and fast secondary-adding is the right shape for a career that will span multiple language waves over decades.

The broader frame

The bigger point is that language anxiety is overwhelmingly displaced career anxiety. People worry about picking the wrong first language because they're really worrying about making an irreversible choice. The choice is reversible. The cost of switching languages after two years is less than the cost of not picking for two years. The bigger failure mode, by far, is deferring the decision and never starting. Pick anything widely used, commit for two years, see what you've built, and re-evaluate. The specific language matters less than the commitment, which is the advice my senior colleagues gave me twenty years ago and has continued to age well.

So: when someone asks you what programming language they should learn, the answer is usually 'what do you want to build', followed by a specific recommendation, followed by a reminder that the first choice is not the last choice. The JavaScript joke is correct within its domain. It's also narrower than it sounds, and the interesting careers happen at the edges where the joke breaks down.

← Previous
Plunge pricing: when the grid pays you to switch on the dishwasher
Next →
Why a tyre company became the world restaurant authority

Discussion

Email used only for your avatar. Never shown, never stored in plain text.