Guido van Rossum on Python 3.11's Speedup, Type Hints, the GIL and the Future of Programming

High-Level Overview

In his second appearance on the podcast, Python creator and "emeritus BDFL" Guido van Rossum, now at Microsoft, talks with Lex Fridman about how Python works and where it is going. They start with the basics of what a programming language and an interpreter are, framed as explaining things to a fisherman and a Silicon Valley programmer on the same boat, then dig into code readability and indentation, the origins of the dollar sign in shell scripts, how many bugs real software has, choosing which technologies to invest in, how CPython 3.11 became 10 to 60% faster, type hints and static type checkers like mypy, TypeScript, IDEs, concurrency and asyncio, the global interpreter lock, whether there will ever be a Python 4, why Python won machine learning, and his experience stepping down as benevolent dictator for life.

The tone is relaxed, technical and gently humorous, with van Rossum's dry understatement playing off Fridman's enthusiasm and occasional self-described therapy sessions about his own tool choices. The conversation moves from concrete implementation details to career advice and, by the end, to philosophical reflections on layers of abstraction in computers, biology and civilization.

The Discussion Explores:

• Readability and indentation: why code is written for other humans as much as for computers.
• Bugs and software resilience: how much buggy code actually runs the world.
• Choosing tools and languages: fads, sunk costs, and not overthinking it.
• Python 3.11's speedup: the adaptive specializing interpreter.
• Type hints and static checking: mypy, competing type checkers, and TypeScript.
• Concurrency, asyncio and the GIL: why threads are hard and what might replace the GIL.
• Python 4, machine learning and community: lessons from the Python 3 transition, and why scientists adopted Python.
• Leadership, careers and the future: stepping down as BDFL, learning to code, Copilot, and Python as future infrastructure.

Deep Dive into Main Ideas

Programs Are Recipes Written for Two Audiences

Van Rossum explains a programming language to the imaginary fisherman as a list of instructions, like a cookbook recipe for making a sandwich, that must be completely unambiguous because computers lack human context. Fridman observes that "ambiguity is a feature, not a bug" in human languages; van Rossum notes that for lawyers it certainly is. CPython, he explains, is the original Python implementation he started over 30 years ago, written in C, and the last implementation standing.

The key insight behind Python's style guide, PEP 8, is that "software is a very social activity." "A software developer is not a mad scientist who sits alone in his lab writing brilliant code." Unlike a recipe written once and followed by many, a program has two audiences at once, the computer and other programmers, and must constantly be debugged and improved, so readability counts. Indentation serves the same purpose as the layout of a good cookbook. Four spaces was a compromise shaped by old conventions and 1980s screen widths; Google uses two, classic Unix uses eight. In Python, indentation is part of the language rather than a style recommendation, though other languages' programmers and IDEs are just as strict in practice.

Would he choose braces today? Context matters: almost every other major language uses curly braces, so Python is the odd one out, and it could never switch now because braces already mean dictionaries. But in a green field he would still argue for indentation, because it reduces clutter, "frees up a pair of matched brackets of which there are never enough in the world for other purposes", and lets beginners spend less time fighting syntax, like misplaced semicolons, when a first programming course already has to cover algorithms, data structures, loops, functions, recursion and more. He explains that the dollar sign before variables in shells, Perl and PHP dates to early script processors that needed a trivially simple way to tell variables from file names, a quirk that persists much like odd features of DNA.

How Buggy Is Software, Really?

Fridman asks how many bugs exist per line of code. Van Rossum recalls research suggesting around one bug per thousand lines in mature software. Fridman finds a vendor report claiming developers create 70 bugs per 1,000 lines, 15 of which reach customers, that fixing a bug takes 30 times longer than writing a line, and that 75% of developer time goes to debugging, which van Rossum suspects is marketing for someone selling a silver bullet. When they try to check Stack Overflow on the topic, it is down for maintenance.

Van Rossum emphasizes that modern software is resilient despite bugs, with error-correcting mechanisms at many levels, including users who reload a page or reboot. He distinguishes typos, caught quickly, from thinkos like forgetting to initialize a variable, and admits he is a poor two-finger typist who first learned the keyboard on punch cards. Fridman describes his Kinesis keyboard, which puts backspace under the thumb, and his lingering attachment to Emacs.

Picking Technologies Without Overthinking It

Fridman recalls investing years in ActionScript, Flash and Java applets, and describes his difficult switch from C++ to Python for machine learning as almost like walking away from a person you love. Van Rossum says replaced technologies often introduced concepts that live on, like reactive web pages, and that young people should try unusual things: nine out of ten times you learn why everyone else does it differently, and one out of ten you discover something better. He cautions against building a spreadsheet to predict lifetime earnings from a language choice, since the inputs are unmeasurable. His advice: accept that not every choice will be perfect, keep a plan B, and don't overthink it.

How Python 3.11 Got 10 to 60 Percent Faster

Van Rossum explains the trade-off between simplicity and performance. When he started Python, he wanted something working in about three months, so he cut corners and wrote code as simply as possible. He illustrates with prime numbers: a naive check tries every divisor, while smarter versions stop at the square root, skip even numbers and check only previous primes, gaining speed at the cost of complexity. Over 30 years, that leaves low-hanging fruit.

Python compiles source into bytecode for an imaginary machine, which the interpreter runs. For 3.11, almost all the work went into the interpreter, not the compiler, and the team did not build a just-in-time compiler. They trimmed internal data structures and, most importantly, built an adaptive specializing interpreter. In Python, "add is generic: it might add integers, floats, strings, lists or user-defined objects, so the interpreter follows pointers to find the right type's add function and does error checking every time. The new interpreter notes what types actually appear at a particular line; if it keeps seeing integers, it swaps in a specialized add-integer instruction that does a quick check and adds directly, falling back to the generic path if the guess is wrong. The heuristic is simple: we assume that the weather tomorrow is going to be the same as the weather today." Someone could construct a pathological program that runs slower, but it would be unrealistic. The trick is well known from other dynamic languages, including Facebook's HHVM for PHP and the JVM, and it preserves the dynamic typing that makes Python friendly to beginners.

Type Hints, mypy and the Static Type Checker Ecosystem

Type hints, introduced by PEP 484, let programmers annotate the types of variables, arguments and return values, and are especially popular at large companies with huge codebases. They are not checked when the code runs. Instead, a separate static type checker reads the code without executing it and flags inconsistencies, like a linter focused on types. Python does not use the annotations to speed up the interpreter, partly because annotations sometimes contain "lies" and enforcing them would break many dynamic programs, though a future version might use them as hints with a fallback. Annotations can be inspected at runtime, and third-party libraries can enforce them, at a performance cost.

Mypy was started by Finnish developer Jukka Lehtosalo; he and van Rossum met at a Python conference around 2013 and agreed on a syntax that required no changes to Python, reusing existing annotation syntax instead of Lehtosalo's original angle brackets. Facebook later built Pyre in OCaml, Google built pytype for its giant monorepo, and Microsoft built Pyright, while PyCharm has its own heuristic checker. Type checkers release far more often than Python's yearly cycle, making them a laboratory of experiments, and once syntax enters the language it can't easily be removed. Van Rossum believes many professional Python developers run a static type checker in continuous integration, most often mypy; a web survey Fridman finds estimates 20 to 30% of Python 3 codebases use type hints. He would recommend TypeScript over plain JavaScript because strict typing helps you keep your head straight about what your code does, and TypeScript's compatibility with JavaScript libraries is key to its success. He notes a stage-one proposal to let JavaScript ignore TypeScript-style annotations natively, and says JavaScript's culture, as essentially the only language of the web client, is shaped by its environment.

Emacs, PyCharm and VS Code

Van Rossum started on vi, used Emacs from the early 1980s until about two years before, and dabbled with PyCharm between 2013 and 2018, mainly to navigate Dropbox's 5-million-line codebase, while doing actual editing in Emacs. He compares PyCharm to driving an 18-wheeler and Emacs to a comfortable Toyota with 100,000 miles. After joining Microsoft he tried VS Code and liked it, and he sees it as the spiritual successor of Emacs: a small core engine with a rich package ecosystem that can extend nearly everything, as Emacs does with Lisp packages. He recalls that writing a PyCharm extension to integrate mypy at Dropbox was a struggle. Fridman confesses he feels he should move on from Emacs, likening it to learning to touch type or switching to Kindle.

Concurrency, asyncio and Why Threads Are Hard

Using the fisherman again, van Rossum explains that one person can tend four fishing rods, since fishing is mostly waiting. Parallelism means genuinely multiple CPUs; concurrency is part reality and part illusion, switching quickly between tasks. Synchronization is hard because human brains are not built to track multiple things at once, like balancing a checkbook while watching a murder mystery. When two pieces of code share a variable, all possible orderings of operations must be anticipated, and "concurrency bugs are just harder." A lock is like a sign on the single oven saying it's in use; a semaphore generalizes that to several ovens, which is what his blog post's one-table restaurant metaphor was about.

Around 2012 to 2014, frustration with Python's old async modules led van Rossum to lead what was then the largest Python enhancement proposal, which became asyncio in Python 3.4. There are two paradigms for handling many network connections: callbacks, where each incoming packet is sorted onto the right stack of work, leading to what he calls aesthetically unpleasing spaghetti code common in JavaScript at the time, and tasks, where each task contains the logic for all stages of a request. He chose tasks because Python already had mechanisms to support them, and it has proved popular, especially for Python web clients.

The GIL, Sub-interpreters and a Possible Python 4

The global interpreter lock exists because Python was written before threads were common. When operating systems added threading in the early 1990s, the team wanted to give Python programmers a safe version, as they had with sockets, but didn't want to rewrite the whole interpreter to be thread safe. The GIL let one interpreter be shared by many threads, which was fine when computers had one CPU. When chip makers moved to multiple cores, people discovered their Python threads still ran on a single core, and the GIL became infamous.

The most likely near-term future, possibly in 3.12, is multiple sub-interpreters, each running an independent Python program with faster communication between them. A developer at Facebook has built a no-GIL fork of CPython that uses all cores with limited single-thread slowdown, but van Rossum isn't convinced enough people need multithreaded speed to justify the complexity and maintenance, and he calls the GIL a pretty nice Goldilocks point between no threads and all threads all the time.

Because of the painful Python 2 to 3 transition, which the team says it underestimated, there will not be a Python 4 anytime soon. The Python 2 end-of-life party planned for PyCon 2020 was cancelled by the pandemic. If Python 4 ever happens, van Rossum imagines it being the moment a no-GIL mode becomes the default: no new syntax or library changes for pure Python code, but C extensions, which power essentially all of data science and machine learning, would need to be recompiled against a new interface. That would require years of warning and an opt-in no-GIL build so extension maintainers, many already short-staffed, could adapt. Personally, he rarely uses third-party packages because his work is tooling for building Python itself, and he notes the standard library is now doing spring cleaning of old modules, some of which he wrote around 1992.

Why Python Won Scientific Computing and Machine Learning

Van Rossum says part of it is simple convention, like everyone agreeing to drive on the same side of the road; Perl once looked set to dominate bioscience thanks to its regular expressions. The bigger reason is that anything was better than C, C++ or Fortran for scientists. People like Paul Dubois at Lawrence Livermore saw in the mid-1990s that scientists needed a higher-level language to tie together Fortran and C++ math libraries. Van Rossum never expected Python to be used for arrays of numbers, but its extensibility let others write efficient array packages; groups like the Hubble Space Telescope team in Baltimore became fans, scientists shared libraries, and new frameworks like TensorFlow adopted Python as the interface users already knew. Fridman adds that MATLAB's closed, paid model kept it out of the open-source sharing culture. Van Rossum values Python's nearly egalitarian community, where you don't need to work at a big tech company to make a difference, and notes the Python Software Foundation spends most of its money on growing the community rather than development.

Stepping Down as BDFL, and Company Cultures

Looking back, van Rossum says, "I probably held on to the position too long." He was extremely stressed for a long time without clearly understanding why. The BDFL role gave the community a clear vision and a steady direction, since people learned to predict how he would decide, rather than lurching back and forth like changing political parties. The steering council that replaced him has kept that steady course without stagnating, and he now enjoys being able to ignore issues outside his interests, focusing on typing, asyncio and the faster interpreter.

On company cultures, he says Dropbox was smaller and more focused but had an annual engineering reorganization in which grand plans were abandoned, even though the product always worked smoothly. He joined Microsoft after briefly retiring because the pandemic showed him work can be fulfilling, and he admires its long history, the engineering inside products like 35-year-old Excel, and Satya Nadella's turnaround from hostility to open source toward embracing it, making room for things like VS Code.

Advice for Programmers and the Role of Copilot

On whether to join a big company or start something, van Rossum says both paths can involve creating new things; some engineers grow into CEOs, like Dropbox's Drew Houston, while others, like himself, are brilliant engineers but, he says, horrible at management. His advice to beginners learning Python: "Find something you actually want to do with it." Wanting to learn a skill in the abstract isn't enough motivation; pick a problem, even an unrealistic one, such as a bot or a quick machine learning project. He mentions a blog post arguing the goal should be to "learn Python in 10 years", and notes that memorizing syntax doesn't make you a coder.

He uses GitHub Copilot every day. Its suggestions are usually slightly wrong but save him a lot of typing, often completing a whole line or a five-to-ten-line function if he names it well. He doesn't think it threatens programmers any more than Stack Overflow did: "It helps you take care of the boring stuff." It works best as a reminder of things you could look up, while the creative work of deciding what to build remains yours.

The Future: Python as Mitochondria

Asked about Python's long-term future, van Rossum predicts "It'll eventually become sort of a legacy language that plays an important role" but that most people don't need to know about, like mitochondria in biology, with others building layers on top. He enjoyed building digital circuits from transistors as a teenager and recently tried, as a mental exercise, to design a flip-flop from relays. He sees himself as covering the middle layer of the technology stack, losing track below NAND gates and above machine learning. They close by reflecting that the brain's massively parallel circuitry simulates a slow, single-threaded interpreter of conscious thought, and that self-replication appears at every level, from DNA to organisms to civilizations.

Conclusion

Guido van Rossum's conversation shows the thinking that has kept Python both beginner-friendly and industrial-strength: treat code as communication between people, keep things simple until performance truly demands otherwise, and evolve carefully, as with 3.11's specializing interpreter, optional type hints and the cautious approach to removing the GIL. His reflections on stepping down as BDFL, the Python 3 transition and Python's egalitarian community offer lessons about leadership and change, while his advice to learners is refreshingly practical: find a project you care about, accept imperfect choices, and let tools like Copilot handle the boring parts. For programmers and the curious alike, it's an accessible look inside one of the world's most important languages from the person who started it.

This is a summary of "#341 – Guido van Rossum: Python and the Future of Programming" from Lex Fridman Podcast, giving you the GIST so you can decide if you want the REST. Listen to the full episode.