Picking a programming language is almost always a trade-off. Python is a strong default for a huge range of tasks, but it isn't the right tool for every job. This chapter compares Python head-to-head with five of the languages it most often gets weighed against: Java, C/C++, JavaScript, Go, and R. We close with a short, honest section on the places where reaching for Python would be a mistake.

Before the comparisons, here's roughly where these languages sit on two axes that matter most: how strict their type system is at compile time, and how fast typical code runs.

The chart is a rough orientation, not a benchmark. A C program crunching numbers in a tight loop will smoke equivalent Python every time. But Python calling into a C library (which is what NumPy and PyTorch do) can match or beat hand-written C for many workloads. Speed depends on what the code is doing, not just what language wraps it.

Java and Python sit on opposite sides of the static-vs-dynamic divide. Java declares every variable's type up front and refuses to compile if those types don't line up. Python lets you assign anything to anything and checks at runtime. That single design decision ripples through almost every other difference between them.

Java compiles to bytecode that runs on the JVM, which JIT-compiles hot methods to native code as the program runs. CPython (the standard Python implementation) compiles to its own bytecode and then interprets it. There's no JIT in CPython by default, which is the main reason CPU-bound Java code typically outruns CPU-bound Python by a factor of two to ten on long-running workloads.

Printing a cart total in both languages makes the syntactic gap concrete.

Python lets you write a three-line script. Java requires a class, a main method, and explicit types for every variable. The trade is real: Java's ceremony catches a category of bugs at compile time that Python wouldn't notice until the line ran. Java's JIT also typically wins CPU-bound benchmarks by a wide margin once the JVM has warmed up.

Pick Python when you're writing data pipelines, scripts, glue code, machine learning, or anything where you want to iterate fast and the heavy lifting happens in C-backed libraries. Pick Java for long-running services where strict typing, predictable performance, and a deep enterprise ecosystem (Spring, Hibernate, Kafka clients) pay for themselves over years of maintenance.

C and C++ are low-level systems languages. Python is a high-level language whose reference implementation is written in C. That relationship matters: most of the time, when Python feels fast, it's because the work is being done by C code that Python is just calling into.

The big philosophical split is memory management. C makes you allocate and free every byte by hand using malloc and free. C++ adds RAII (Resource Acquisition Is Initialization), so destructors clean up automatically when an object goes out of scope, but you still control allocation explicitly. Python hides all of it behind a reference-counting garbage collector. You never allocate, never free, never think about pointers.

A simple "print and sum" looks roughly like this in each:

The C version is longer, requires a header include, a fixed-size array, an explicit loop counter, and a return 0. In exchange, the compiled binary runs without any interpreter and uses a fraction of the memory.

Pick C or C++ when raw speed or fine-grained control over memory is the whole point: operating system kernels, real-time audio, embedded firmware, game engines, browser internals, GPU code, and the numeric kernels that libraries like NumPy and PyTorch are built on. Pick Python when developer speed and readability matter more than wall-clock speed, which is most of the time outside systems work. The honest rule of thumb is: write it in Python first, then drop into C only for the part the profiler tells you is the bottleneck.

Python and JavaScript get compared often because they're both dynamically typed, both wildly popular, and both first-choice languages for beginners. But they grew up in very different environments, and that history still shapes where each one shines.

JavaScript was built to run in the browser. Every web page you visit today executes JavaScript inside an engine like V8 (Chrome, Node.js), JavaScriptCore (Safari), or SpiderMonkey (Firefox). Python was built to run on a Unix shell as a scripting language for system tools, and over the decades grew into the dominant language for data, scientific computing, and back-end scripting. JavaScript later moved server-side with Node.js, so today both languages can run a web backend, but JavaScript still owns the browser completely.

Greeting a customer in each:

The shape is similar, but the surrounding rules differ. JavaScript has let, const, and var, three different ways to declare a binding, each with different scoping rules. Python has one: just assign. JavaScript coerces types aggressively ("5" + 3 produces "53", "5" - 3 produces 2). Python refuses to mix incompatible types and raises TypeError instead.

Pick JavaScript (or TypeScript) when you're writing anything that runs in a browser, building a Node-based backend in a team that's already deep in the JS ecosystem, or shipping a desktop app via Electron or Tauri. Pick Python for data work, machine learning, scripting, automation, scientific computing, or back-end services where the team isn't already locked into Node. For a brand-new web backend with no constraints, both are reasonable, the choice usually comes down to what the rest of the stack looks like.

Go was designed at Google in 2009 to give systems engineers a language that compiled fast, deployed as a single binary, and made concurrency easy. Python predates Go by almost 20 years and was designed for very different goals. The contrast is sharp.

Go is statically typed, compiled to a native binary, and has goroutines (lightweight threads managed by the Go runtime) as a built-in concurrency primitive. You can launch a hundred thousand goroutines on a laptop without breaking a sweat. Python is dynamically typed, interpreted, and has historically been limited by the GIL (Global Interpreter Lock), which prevents threads from running Python bytecode in parallel on multiple CPU cores. Python's answer for concurrency is asyncio for I/O-bound work and multiprocessing for CPU-bound work. Python 3.13 introduced an experimental free-threaded build that disables the GIL, but it isn't the default yet.

A trivial HTTP-ish "hello" looks like this in each:

Go forces you to declare a package, import what you use, and type every parameter and return. The reward is a single compiled binary you can scp to a server and run without installing anything else. No interpreter, no virtual environment, no pip install.

Pick Go for network services that need to scale to many concurrent connections, CLI tools you want to ship as a single binary, and cloud-infrastructure code (Kubernetes, Docker, Terraform, and most of the CNCF stack are written in Go). Pick Python when you need the data and ML ecosystem, when readability and speed of writing matter more than raw concurrency, or when you're gluing together services that other people built.

This comparison is narrower than the others. R isn't a general-purpose language, it's a statistics-first environment that grew out of academic statistics in the early 1990s. Python and R only really overlap in the data analysis and machine learning space, which is where the rivalry lives.

R was designed by statisticians for statisticians. It treats vectors and data frames as first-class citizens, ships with built-in statistical functions for things like linear regression and t-tests, and has the tidyverse (dplyr, ggplot2, tidyr) for data manipulation and visualization that many statisticians still prefer over anything Python offers. Python is a general-purpose language that happens to have grown a remarkable data stack: NumPy for numeric arrays, pandas for data frames, scikit-learn for classical ML, PyTorch and TensorFlow for deep learning, and matplotlib and seaborn for plotting.

Computing the mean of a list of order totals in each:

R's mean() is built in. Python's lives in the statistics standard library module (or in NumPy, or in pandas). R's assignment uses <-, vectors are constructed with c(), and operations like mean are vectorized by default. Python needs a library import to get the same convenience.

Pick R when you're doing academic statistics, biostatistics, econometrics, or any environment where peer-reviewed statistical methods and high-quality plotting (ggplot2) are the deliverable. Pick Python when the work needs to integrate with production systems, web services, machine learning pipelines, or any code that has to ship and run beside other software. Most data teams today default to Python because the same language that builds the model also builds the API that serves it.

Python is a strong default, not a universal answer. There are concrete categories of work where it's the wrong tool, and being honest about them is part of being a good Python engineer.

GPU-tight machine learning kernels are written in CUDA C++, Triton, or hand-tuned assembly, not in Python. PyTorch itself is mostly C++ and CUDA under the hood; you write Python to call into it. Hard real-time systems (avionics, anti-lock brakes, industrial control loops where missing a deadline by a millisecond causes physical damage) need predictable, garbage-collector-free execution and are typically written in C, C++, or Ada. Native mobile apps target Swift on iOS and Kotlin on Android; Python can do mobile through frameworks like Kivy or BeeWare, but it isn't the mainstream choice and you'll fight the ecosystem.

For CLI tools that you want to distribute to people who don't have Python installed, Go's single static binary often beats Python's "install Python, set up a venv, pip install the tool". Browser frontends are JavaScript or TypeScript territory; Python doesn't run natively in browsers (Pyodide compiles CPython to WebAssembly, but it's a heavy runtime download and a niche choice). And for the lowest layers of a system, kernels, drivers, embedded firmware on a microcontroller with 32KB of RAM, Python's interpreter and runtime simply don't fit. C, C++, and Rust own those layers for good reasons.