Nathan Goldbaum: Slaying Python's GIL and Charting a Course Through Technical Ecosystems

Nathan Goldbaum stands at the forefront of one of Python's most significant transformations in recent years: the removal of the Global Interpreter Lock (GIL) and the transition to free-threading. In a recent conversation, Goldbaum shared insights into his technical work, career path, and philosophy, revealing a developer deeply engaged with both the technical and human aspects of software development.

The Free-Threaded Revolution

Goldbaum's primary focus has been on spearheading the effort to remove Python's GIL, a project that has far-reaching implications for the entire Python ecosystem. "It's for people who understand Amdahl's law," he explains. "You'll always have CPU-bound pure-Python code to orchestrate low-level code that releases the GIL, so no matter how well your low-level code scales, Pure Python code and the GIL will eventually show up as a scaling bottleneck for almost any arbitrary Python code if you want to exploit your 100-core Threadripper."

This monumental undertaking, funded by Meta through Quansight, requires updating foundational libraries like NumPy, Cython, and setuptools to work without the GIL. The technical challenges are substantial, particularly regarding ABI compatibility. "The free-threaded interpreter has a completely different ABI, a different layout to PyObject structs," Goldbaum notes. "There needs to be Rust code explicitly listing out the ABI down to the byte level, so the pyo3-ffi crate is basically rewriting the CPython headers with extra complexity for older Python versions via conditional compilation."

The testing approach has been equally innovative. For free-threaded build support, the team uses pytest-run-parallel, a PyTest plugin that runs each test in a suite many times simultaneously in a thread pool. "It's not perfect, it won't validate thread safety for mutable data structures, but it will find implementations that rely on global state," Goldbaum explains.

From Astrophysics to NumPy: A Career Path Defined by Problem Solving

Goldbaum's journey to becoming a key contributor to NumPy and PyO3 began not in software development, but in astrophysics. "I started my career writing software to analyze simulations of galaxies which transitioned into working on software that makes grad students' lives easier," he reflects. "So I work on complicated Python projects which help others work on projects more directly important to society itself."

His entry into open source was almost accidental, typical of many PhD students who find themselves contributing to tools rather than their primary research. "A common pathology of hard science PhDs is: Get paid to work on something so huge no human could do it, discouraging you until you get distracted by something tractable," Goldbaum observes. "Your project needs software, you see an existing OSS project doing it, which you naturally fix. While fixing it, you interact with people on GitHub. It's both more enjoyable and more social than grad work."

This dopamine hit from merging pull requests eventually led to more substantial contributions, ultimately earning him commit bits on NumPy and PyO3. "I discovered an unusual career niche and it's nice to show people it's possible," he says.

The Evolving Python Ecosystem

Goldbaum offers a nuanced perspective on the current state and future direction of Python's package management and technical ecosystem. Regarding package management, he sees positive developments: "The Conda ecosystem is really nice. The community-maintained conda-forge package ecosystem makes stuff instantly available and installable in a uniform way on the main OSs, great especially for native dependencies."

He's particularly excited about newer tools like Pixi, which allows for lock files with defined environments, similar to uv's relationship with Pip. "I'm excited because conda packages can build the package too. So Pixi could recursively build everything in an environment from source, enabling sanitizer testing for packages all over the ecosystem."

When it comes to native code extensions, Goldbaum is clear about his preferences. "I don't think C or C++ is a good choice for native, greenfield code in 2026. I'd also always choose Rust over Cython; writing in a safe language with tooling and which doesn't compile to generated C is so much more pleasant. We should be handing people shovels not grenades."

The main blocker to wider Rust adoption in the scientific Python ecosystem, according to Goldbaum, is better support in build systems. "The main blocker to getting this going in the Python community is adding better support for Rust and PyO3 projects to meson and meson-python. PyO3 is tightly coupled to Python. Maturin manages this complexity, but meson-python will need to do something similar if it wants to directly support PyO3-based Rust projects."

Public Engagement and Open Science

Goldbaum maintains a visible public presence under his real name, a choice he views as both a privilege and a responsibility. "It's my privilege as a white dude with a US passport where I feel like I can have an online presence and participate in online communities with my real name without people bouncing down my door and telling me how much of a piece of shit I am. So far that hasn't happened. If it ever happens, I might change my stance."

His commitment to openness extends to his academic background. "In academia, I was into open science. In astrophysics people would often keep their secret sauce, publishing papers about simulations whose code and data was private. A large fraction of the literature is worthless because you have to take it on faith they didn't have some bug."

This philosophy continues to guide his technical contributions. "I find it personally satisfying to help people asking technical questions, if I know the answer. It's my karmic way of paying back."

Burnout and Sustainable Work Practices

Perhaps surprisingly for someone with around 1500 GitHub contributions in 2025, Goldbaum has experienced significant burnout. "I definitely don't work on code very much outside of working hours. I burned out pretty hard and quit my job in 2020 and was not working for a few years," he shares candidly.

His recovery involved therapy and medication, something he wishes he had pursued earlier in his career. "I really wish I had started antidepressants in grad school. It would have helped me a lot. But for some reason, I had a mental block or had told myself that I would be like cheating or something or that like, yeah, the medication is bad."

Now, he structures his work to prevent burnout. "I have tried to structure things so that work is very timelocked to 35 hours a week. At Quansight I have to put hours in a time sheet, which timeboxes me so they can't legitimately ask me to like be on call on the weekend or something."

His approach to management reflects these values. "It's the Dutch management style, which I learned from Ralf. You just say what you mean and you accept people as humans. Sometimes people aren't able to do what we're asking of them, so I try to make space for them to contribute."

Version Control: From Mercurial to Jujutsu

Goldbaum's technical interests extend beyond Python to version control systems. He worked on a Mercurial client at the Recurse Center, drawn to the technical discussions in the Mercurial IRC channel. "I wanted a concrete project to learn Rust, spread out over multiple files," he explains.

He sees Mercurial's legacy continuing in Jujutsu, particularly in its UI design with revsets. "Many of the Mercurial IRC people are now in the JJ discord too!" he notes.

When asked about why major companies moved away from Mercurial, Goldbaum points to practical realities. "All the tooling in the universe is built around Git; a lot of tooling assumes any code in a repository is in Git. The only fix is to treat version control like an abstract system with an adapter for each alternative, which no one wants to do."

Looking to the future, he's optimistic about Jujutsu's potential. "To really replace Git, you need it usable for things besides text files. People want to version arbitrary binary files, natively. Figuring out semantic diffs as a first class thing, not just binary blobs."

Documentation-Driven Development

Goldbaum places particular emphasis on clear documentation, both as a communication tool and as a design methodology. "A lot of my job is communicating, writing things on GitHub, so I try to write as clearly as possible. It's enjoyable though also time-consuming and labor-intensive, to draft a bigger document but worthwhile especially for technically complex work."

He particularly values documentation-driven development. "I really like documentation driven design where I write the docs or example programs which demonstrate what I want to be able to do. After implementing a prototype, you can then compare with the examples and documentation to find bugs (whether in the implementation or design)."

Among his documentation work, he's particularly proud of the free-threading guide, NumPy's StringDType documentation, and the documentation for unyt, a library for unit conversions in scientific computing.

Looking Ahead

With free-threading making steady progress, Goldbaum is already thinking about what comes next. "I have a list of things in NumPy like improving the next iteration of StringDType, NumPy's variable-width utf-8 text data type. It'd be nice for it to support other encodings. It'd also be nice to have a BytesDType to go along with StringDType for cases where there is no valid encoding or the encoding is unknown."

He predicts that free-threading will become the default Python build relatively soon: "Maybe 3.16 or 3.17. That depends on community uptake, how people feel about it and how fast we address the issues the steering council identified."

As for the broader Python ecosystem, Goldbaum sees Rust playing an increasingly important role, particularly in performance-critical components. "Many problems with NumPy are because changing the C code is so difficult; it'd be nice to work in a language where I can refactor things without feeling like I've broken something."

Ultimately, Goldbaum's work represents a thoughtful approach to technical development—one that balances performance improvements with sustainability, both for the software and the people creating it. As Python continues to evolve, developers like Goldbaum, who can navigate complex technical challenges while maintaining a human-centered perspective, will be invaluable to the ecosystem's future.