Python

Python and Rust Have the Same Supply Chain Problem as NPM

Last post I walked through the threat model for supply chain attacks and dug into the NPM ecosystem specifically: postinstall scripts, npm ci, pnpm’s release-age cooldown. The same structural problems exist in Python and Rust, but the failure modes are different and the tooling has evolved in some surprising directions. Worth understanding both, because if you write any backend code in 2026 you’re probably touching at least one of these ecosystems.

Python: setup.py Is a Remote Code Execution Primitive

The thing most Python developers don’t appreciate is that pip install runs arbitrary code by default. Not after install. During install. If a package ships a setup.py, that file is executed in a Python interpreter the moment pip resolves the dependency. Whatever the author wrote, including reading ~/.aws/credentials, scraping environment variables, or opening a reverse shell, runs as your user with full filesystem access.

This is the part that confuses people coming from other ecosystems: venv and virtualenv don’t help. They isolate Python package versions to avoid conflicts. They are not a security boundary. A package installed inside a virtualenv has the exact same privileges as the user who ran pip install. None of this is a bug, exactly. It’s just an artifact of setup.py being a regular Python script that pip has always been willing to execute.

The defense-in-depth stack for Python looks like this:

Stop using pip. I mean it. pip is the worst package manager in mainstream use today and it is the single biggest reason Python’s supply chain story is a disaster. It has no native lockfile. requirements.txt is a shopping list, not a lockfile; it tells pip what to fetch, not what you actually got last time. Run pip install -r requirements.txt twice on two different days and you can get two different dependency trees, because pip resolves transitive deps fresh every time against whatever happens to be on PyPI in that moment. Builds aren’t reproducible. Hashes aren’t verified by default. There’s no separation between “what I asked for” and “what was actually resolved.”

Every other ecosystem solved this a decade ago. npm has package-lock.json. Cargo has Cargo.lock. Bundler has Gemfile.lock. pip has vibes.

The --require-hashes flag exists, technically, but it’s duct tape on a broken design. You have to generate the hashes with a separate tool (pip-tools), maintain them by hand, and remember to pass the flag on every install. Nobody does this in practice. The Python Packaging Authority spent fifteen years insisting pip was fine while every other community built proper lockfile-based managers.

Use uv or Poetry. Both produce real lockfiles with SHA-256 hashes for every direct and transitive dependency, both make installs reproducible by default, both are dramatically faster than pip. uv in particular is the obvious default for new projects in 2026, it’s a drop-in replacement that’s roughly 10-100x faster and treats the lockfile as a first-class artifact instead of an afterthought. Hash verification isn’t a flag you have to remember. It’s how the tool works.

This doesn’t protect you from a malicious package you pinned on day one. But it does slam the door on silent registry tampering, makes “what’s actually deployed?” a question with an answer, and gets you out of the pip swamp.

pip-audit for known vulnerabilities. Scans your environment or requirements file against the OSV database, PyPA advisories, and GitHub advisories. Run it in CI. Combined with a real lockfile you get a tight loop: pin exact versions, scan those versions for CVEs, fail the build if anything critical shows up.

Trusted Publishing (OIDC). If you maintain a package on PyPI, get rid of your long-lived API token and switch to OIDC-based publishing. Your CI runner generates ephemeral, short-lived tokens scoped to a specific repository, branch, and workflow. Leaked PyPI tokens have been the source of multiple high-profile compromises. Trusted Publishing makes the credential effectively un-leakable because it doesn’t exist as a persistent secret.

The thing I’d actually call out, though, is that none of the Python tooling addresses the setup.py execution problem at install time. Hash pinning verifies you got the right bytes. It doesn’t tell you those bytes aren’t malicious. For that you’re back to either sandboxing the install (Docker, devcontainers) or trusting the registry’s malware detection, which lags by hours to days.

Rust: The Safety Guarantees Stop at the Compiler

Rust’s reputation for safety is real, but it’s a property of the compiled language, not the supply chain. The borrow checker doesn’t help you when the crate you’re depending on exfiltrates your SSH key during cargo build.

The mechanism is build.rs. Crates can include a build script that runs before the compiler, with full user privileges. Procedural macros do the same thing at compile time. In both cases, the code can read files, open network sockets, do whatever it wants. A malicious build.rs is effectively an unsandboxed unsafe block that bypasses code review because nobody reads build scripts. The Rust core team has been discussing sandboxing for years, but nothing has shipped.

This isn’t theoretical. Two examples from the last six months:

September 2025: faster_log and async_println were caught scraping Ethereum and Solana private keys at runtime and exfiltrating them to Cloudflare workers.
March 2026: chrono_anchor, dnp3times, and time-sync, all masquerading as time utilities, were transmitting .env file contents to threat actors.

Both clusters used compromised GitHub OAuth credentials to push under legitimate-looking namespaces. crates.io authenticates via GitHub, so a phished GitHub account is a phished crates.io account.

The defensive tooling is actually better than what most ecosystems have:

Tool	What it does
`cargo-audit`	Scans `Cargo.lock` against the RustSec Advisory Database. Run in CI.
`cargo-deny`	Lints the dependency graph. Block specific crates, enforce license policies, restrict registries.
`cargo-crev`	Decentralized “web of trust” where developers cryptographically sign crate reviews. Elegant, but heavy lift in practice.
`cargo-vet`	Mozilla’s pragmatic answer to crev. Centralized audit records per org, with the ability to import audits from peer orgs (Google, Mozilla, Embark) instead of re-auditing every transitive dep yourself.

If you’re picking one to start with, cargo-audit is the easy baseline. It’s npm audit for Rust and you should be running it in CI yesterday. cargo-deny is the next step up. It lets you actually enforce policy, which is what you want once you’ve used cargo-audit long enough to be tired of triaging the same warnings.

cargo-vet is the interesting one for any team beyond about five engineers. The insight is that you don’t actually need to audit every crate. You just need to know that someone you trust did. By importing audit records from Mozilla and Google, a small team can effectively delegate the audit work for hundreds of common dependencies without running anything themselves. It’s the closest thing the Rust ecosystem has to a working trust network, and it works because the cryptographic overhead lives at the org level instead of being pushed onto individual developers.

The Pattern Across All Three Ecosystems

NPM, PyPI, and crates.io all share the same fundamental design flaw: package installation executes attacker-controlled code by default. NPM has postinstall. Python has setup.py. Rust has build.rs and proc macros. Different files, same problem.

The mitigations also rhyme. Lock your versions to specific hashes. Run an audit tool in CI. Where possible, prevent install-time execution entirely (--ignore-scripts, pre-built wheels, sandboxed build scripts when they finally land in Cargo). Where you can’t, isolate the install with devcontainers, ephemeral CI runners, anything that contains the blast radius when a dependency turns out to be hostile.

Next post I’ll get into the isolation side specifically: devcontainers, OrbStack, Landlock, and the practical question of how a solo developer with no security budget actually keeps their laptop from getting owned by an AI agent that just pip installed a hallucinated package name.

Sources

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

May 15, 2026 / DevOps / Python / security / Rust / Supply-chain

The Human's Guide to the Command Line: From Script to System
This is Part 3 of The Human’s Guide to the Command Line. If you missed Part 1 or Part 2, go check those out first, you’ll need the setup from both.

In Part 2, we built a note-taking app. It works. But running it looks like this:
```
uv run ~/code/note/note.py add "call the dentist"
```
That’s… not great. Real command-line tools don’t make you remember where a Python file lives. You just type the name and it works. By the end of this post, you’ll be able to type:
```
note add "call the dentist"
```
From anywhere on your computer. Let’s make that happen.

Why Can’t I Just Type note?

When you type a command like ls or brew, your shell doesn’t search your entire computer for it. It checks a specific list of directories, one by one, looking for a program with that name. That list is called your PATH.

You can see yours right now:
```
echo $PATH
```
You’ll get a long string of directories separated by colons. Something like /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin. When you type brew, the shell checks each of those directories until it finds a match.

Right now, note.py is sitting in ~/code/note/. That folder isn’t in your PATH, so the shell has no idea it exists. We need to turn our script into something installable, and put it somewhere the shell knows to look.

Restructuring Your Project

Python has specific expectations about how a project needs to be organized before it can be installed as a tool. Right now your project looks like this:
```
note/
  pyproject.toml
  note.py
```
We need to reorganize it into a package. Here’s what we’re aiming for:
```
note/
  pyproject.toml
  src/
    note/
      __init__.py
      cli.py
```
Let’s do it step by step. Open Ghostty and navigate to your project:
```
cd ~/code/note
```
Create the new directories
```
mkdir -p src/note
```
The -p flag means “create parent directories too.” This creates both src/ and note/ inside it in one shot.

Move your script
```
mv note.py src/note/cli.py
```
Your note-taking code now lives at src/note/cli.py instead of note.py.

Create the package marker
```
touch src/note/__init__.py
```
This creates an empty file. Python uses __init__.py to recognize a folder as a package — it can be completely empty, it just needs to exist.

Update pyproject.toml

Open your project in Zed:
```
zed .
```
Find pyproject.toml in the sidebar and open it. You need to add two things. First, tell uv where your code lives by adding this section:
```
[tool.uv]
package = true
```
Then add this section to define your command:
```
[project.scripts]
note = "note.cli:main"
```
That line is doing something specific: it’s saying “when someone types note, find the note package, go into the cli module, and call the main function.” That’s the same main() function at the bottom of the code we wrote in Part 2.

Your full pyproject.toml should look something like this (the exact version numbers may differ):
```
[project]
name = "note"
version = "0.1.0"
description = "A simple command-line note taker"
requires-python = ">=3.12"
dependencies = []

[tool.uv]
package = true

[project.scripts]
note = "note.cli:main"
```
Verify the structure

Run this in Ghostty to make sure everything looks right:
```
ls -R src/
```
You should see:
```
src/note:
__init__.py  cli.py
```
Installing It For Real

Here’s the moment. From your project directory (~/code/note), run:
```
uv tool install .
```
That . means “install the project in the current folder” — same dot from Part 2 when we ran zed . to mean “open this folder.”

What just happened? uv created an isolated environment for your tool and dropped a link to it in ~/.local/bin/. That directory is on your PATH (or should be), which means your shell can now find it.

Try it:
```
note list
```
You should see your notes from Part 2 (or “No notes yet” if you cleared them). Try adding one:
```
note add "I installed my first CLI tool"
note list
```
That works from anywhere. Open a new terminal tab, navigate to your home directory, your Desktop, wherever… note just works now.

If you get “command not found”: Run uv tool update-shell and then restart your terminal. This adds ~/.local/bin to your PATH in .zshrc so your shell knows where to find tools installed by uv.

One thing to know about editing

When you ran uv tool install ., uv copied your code into its own isolated environment. That means if you go back and edit src/note/cli.py, your changes won’t show up until you reinstall:
```
uv tool install --force .
```
The --force flag tells uv to overwrite the existing installation. During development, you could also use uv tool install -e . (the -e is for “editable”) which keeps a live link to your source code so changes show up immediately without reinstalling.

You went from a Python script you had to run with uv run note.py to a real command that works from anywhere on your machine.

Welcome to your first CLI!
Apr 15, 2026 / Programming / Python / Cli

Enjoyed this?
The Human's Guide to the Command Line: Your First CLI App
This is Part 2 of The Human’s Guide to the Command Line. If you missed Part 1, go check that out first — we got Homebrew and Ghostty set up, which you’ll need for everything here.

Now we’re going to do something that feels like a big leap: we’re going to write a real command-line application. A small one, but a real one. Before we get there, though, we need two things — a programming language and a code editor.

Picking a Language

You can write CLI apps in a lot of languages. JavaScript, Go, Rust — they all work. But if you’re new to programming, I think Python is the right starting point. It reads almost like English, it’s everywhere, and you won’t spend your first hour fighting a compiler.

Python is what we’ll use for this series. That said, Python is notoriously tricky to set up locally; there are version managers, virtual environments, and a whole ecosystem of packaging tools that can make your head spin.

First things first, we need a code editor (an IDE).

A Code Editor: Zed

Before we write any code, you need somewhere to write it. We’re going to install Zed — it’s fast, clean, and won’t overwhelm you with buttons.
```
brew install --cask zed
```
Open Zed from your Applications folder once it finishes.

Install the zed Command

Here’s the move that ties everything together. Open Zed’s command palette with Cmd + Shift + P, type cli install, and hit Enter.

Now you can open any folder in Zed directly from Ghostty:
```
zed .        # open the current folder
zed note.py  # open a specific file
```
That . means “right here” — you’ll see it everywhere in the terminal and it always means the same thing: the folder you’re currently in.

Set Up Your Project

Time to create a home for your code. Back in Ghostty:
```
mkdir ~/code
mkdir ~/code/note
cd ~/code/note
```
Three commands. You just created a code folder in your home directory, created a note folder inside it, and stepped into it. Now open it in Zed:
```
zed .
```
Zed opens with your empty project folder in the sidebar on the left. This is where we’ll create our script.

Building a Note Taker

We’re going to build a tiny app called note. It does three things: add a note, list your notes, and clear them all. That’s it. No database, no accounts, no cloud. Just you and a JSON file.

Create your script in Zed’s sidebar by clicking the New File icon, name it note.py, and paste in the code from the next section.
```
import argparse
import json
import sys
from datetime import datetime
from pathlib import Path

# Where your notes live — ~/notes.json
NOTES_FILE = Path.home() / "notes.json"


def load_notes():
    if not NOTES_FILE.exists():
        return []
    with open(NOTES_FILE) as f:
        return json.load(f)


def save_notes(notes):
    with open(NOTES_FILE, "w") as f:
        json.dump(notes, f, indent=2)


def cmd_add(args):
    notes = load_notes()
    note = {
        "text": args.text,
        "added": datetime.now().strftime("%Y-%m-%d %H:%M"),
    }
    notes.append(note)
    save_notes(notes)
    print(f"Added: {args.text}")


def cmd_list(args):
    notes = load_notes()
    if not notes:
        print('No notes yet. Add one with: note add "your note"')
        return
    for i, note in enumerate(notes, start=1):
        print(f"{i}. {note['text']}  ({note['added']})")


def cmd_clear(args):
    answer = input("Delete all notes? This can't be undone. (y/n): ")
    if answer.lower() == "y":
        save_notes([])
        print("All notes cleared.")
    else:
        print("Cancelled.")


def main():
    parser = argparse.ArgumentParser(
        prog="note",
        description="A simple command-line note taker.",
    )
    subparsers = parser.add_subparsers(dest="command")

    # note add "some text"
    add_parser = subparsers.add_parser("add", help="Add a new note")
    add_parser.add_argument("text", help="The note to save")

    # note list
    subparsers.add_parser("list", help="Show all notes")

    # note clear
    subparsers.add_parser("clear", help="Delete all notes")

    args = parser.parse_args()

    if args.command == "add":
        cmd_add(args)
    elif args.command == "list":
        cmd_list(args)
    elif args.command == "clear":
        cmd_clear(args)
    else:
        parser.print_help()


if __name__ == "__main__":
    main()
```
Part 3: Python Without the Mess (uv)

Your Mac already has Python on it, but don’t use it. That version belongs to macOS which it uses internally, and if you start installing things into it you can cause yourself real headaches. We’re going to use our own Python that’s completely separate.

The tool for this is uv. It manages Python for you and keeps everything isolated so you never touch the system version.
```
brew install uv
```
That’s the whole install. Verify it worked:
```
uv --version
```
You should see a version number printed back. If you do, you’re good.

Create Your Project

Inside your ~/code/note folder, run:
```
uv init
```
This sets up a proper Python project in the current folder. You’ll see a few new files appear in Zed’s sidebar, but don’t worry. If you see a hello.py, which uv creates as a starter file, you can delete it.

Running Your Script

Once you have code in note.py, run it like this:
```
uv run note.py add "call the dentist"
uv run note.py list
uv run note.py clear
```
uv run handles everything — it picks the right Python version, keeps it sandboxed to this project, and runs your script. You never type python3 directly, you never activate a virtual environment, you never install packages globally. It just works.

Try it now:
```
uv run note.py list
```
If you see No notes yet. Add one with: note add "your note" but otherwise, everything should be working.

Try this: Once your script is running, try uv run note.py --help. You’ll get a clean description of every command, automatically. That’s one of the things argparse gives you for free.
Apr 3, 2026 / Programming / Python / Tutorial / Command-line

Enjoyed this?
Garbage Collection: How Python, JavaScript, and Go Clean Up After Themselves
It’s Garbage day for me IRL and I wanted to learn more about garbage collection in programming. So guess what? Now you get to learn more about it too.

We’re going to focus on three languages I work with mostly, Python, JavaScript, and Go. We will skip the rest for now.

Python: Reference Counting

Python’s approach is the most straightforward of the three. Every object keeps track of how many things are pointing to it. When that count drops to zero, the object gets cleaned up immediately. Simple.

There’s a catch, though. If two objects reference each other but nothing else references either of them, the count never hits zero. That’s a reference cycle, and Python handles it with a secondary cycle detector that periodically scans for these orphaned clusters. But for the vast majority of objects, reference counting does the job without any fancy algorithms.

JavaScript (V8): Generational Garbage Collection

Most JavaScript you encounter is running on V8… so Chrome based browsers, Node and Deno. V8 uses a generational strategy based on a simple observation: most objects die young.

V8 splits memory into two main areas:
- The Nursery (Young Generation): New objects land here. This space is split into two halves and uses a scavenger algorithm. It’s fast because it only deals with short-lived variables — and most variables are short-lived.
- Old Space (Old Generation): No, not the deodorant company. Objects that survive a couple of scavenger rounds get promoted here. Old space uses a mark-and-sweep algorithm, which is slower but handles long-lived objects more efficiently.
First it asks, “How long has this object been around?” New stuff gets the quick treatment, and anything that sticks around gets put out to the farm, to be delt where time is less of a premium. It’s a smart tradeoff between speed and memory efficiency.

Go: Tricolor Mark-and-Sweep

Go’s garbage collector also uses mark-and-sweep, but with a twist called tricolor marking. Here’s how it works:
- White objects: These might be garbage but haven’t been checked yet. Everything starts as white.
- Gray objects: The collector has reached these, but it hasn’t scanned their children (the things they reference) yet.
- Black objects: These are confirmed alive — the collector has scanned them and all their references.
The collector starts from known root objects, marks them gray, then works through the gray set — scanning each object’s references and marking them gray too, while the scanned object itself turns black. When there are no more gray objects, anything still white is unreachable and gets cleaned up.

Go’s approach is notable because it runs concurrently. This helps with latency while the GC is running.

Garbage, Collected

Each approach reflects the language’s priorities:
- Python optimizes for simplicity and predictability. Objects get cleaned up correctly when they’re no longer needed
- JavaScript optimizes for speed in interactive applications. Quick cleanup for short-lived objects, thorough cleanup for the rest
- Go optimizes for low latency. Concurrent collection is great for server side processes
References
- Design of CPython’s Garbage Collector — Python Developer’s Guide deep dive into reference counting and cycle detection
- Orinoco: Young Generation Garbage Collection — V8’s parallel scavenger and generational GC design
- A Guide to the Go Garbage Collector — Official Go documentation on the concurrent tricolor collector
Mar 19, 2026 / Programming / Golang / Python / javascript / Garbage-collection

Enjoyed this?
I wrote about why you should stop using pip. Poetry or uv. Pick one. pip has no lockfile, no dependency resolution worth trusting, and no isolation by default.

Have you moved to uv yet? Still happy with poetry? How’s it going?

Mar 13, 2026 / Programming / Tools / Python
I wrote about when to reach for Python over Bash. Most veterans put the cutoff at 50 lines. If you’re writing nested if statements in Bash, you’ve already gone too far.

Where does Go fit in though? Overkill for scripts?

Mar 13, 2026 / Programming / Python / Bash
When to Use Python Over Bash
When to use python over bash is really a question of when to use bash. Python is a general-purpose language that can handle just about anything you throw at it. Bash, on the other hand, has a very specific sweet spot. Once you understand that sweet spot, the decision makes itself.

What Bash Actually Is

Bash is an interactive command interpreter and scripting language, created in 1989 for the GNU project as a free software alternative to the Bourne shell. It pulled in advanced features from the Korn shell and C shell, and it’s been commonly used by Unix and Linux systems ever since.

What makes Bash unique is its approach to data flow programming. Files, directories, and system processes are treated as first-class objects. Bash is designed to take advantage of utilities that almost always exist on Unix-based systems. So think of tools like awk, sed, grep, cat, and curl. Another important thing to know when writing effective Bash scripts, you also need to understand the pipeline operator and how I/O redirection works.

A good Bash script will look something like this:
```
#!/bin/bash
set -euo pipefail

LOG_DIR="/var/log/myapp"
DAYS_OLD=30

find "$LOG_DIR" -name "*.log" -mtime +"$DAYS_OLD" -print0 |
  xargs -0 gzip -9

echo "Compressed logs older than $DAYS_OLD days"
```
Simple, portable, does one thing well. That’s Bash at its best.

Where Bash Falls Short

Bash isn’t typed. There’s no real object orientation. Error handling is basically set -e and hoping for the best. There’s no try/catch, no structured exception handling. When things go wrong in a Bash script, they tend to go wrong quietly or spectacularly, with not much in between.

Python, by contrast, is optionally strongly typed and object-oriented. If you want to manipulate a file or a system process in Python, you wrap that system entity inside a Python object. That adds some overhead, sure, but in exchange you get something that’s more predictable, more secure, and scales well from simple scripts to complex logic.

Here’s that same log compression task in Python:
```
from pathlib import Path
import gzip
import shutil
from datetime import datetime, timedelta

log_dir = Path("/var/log/myapp")
cutoff = datetime.now() - timedelta(days=30)

for log_file in log_dir.glob("*.log"):
    if datetime.fromtimestamp(log_file.stat().st_mtime) < cutoff:
        with open(log_file, "rb") as f_in:
            with gzip.open(f"{log_file}.gz", "wb") as f_out:
                shutil.copyfileobj(f_in, f_out)
        log_file.unlink()
```
More verbose? Absolutely. But also more explicit about what’s happening, easier to extend, and much easier to add error handling to.

The Performance Question

In some cases, performance genuinely matters. Think high-frequency trading platforms, edge devices, or massive clusters. Bash scripts excel here because there’s almost zero startup overhead. Compare that to Python, which needs to load up the interpreter before it can start executing code. You’re going from microseconds to milliseconds, and sometimes that matters.

But startup time is just one factor. When you compare the actual work being done, Python can pull ahead. String manipulation on structured data? Python wins. Parsing JSON, YAML, or any structured format? Python’s core libraries are written in C and optimized for exactly this kind of work. If you find yourself reaching for jq or yq in a Bash script, that’s a strong signal you should be using Python instead.

The Guidelines People Throw Around

You’ll see a common guideline online: if your script exceeds 100 lines of Bash, rewrite it in Python. But a lot of veterans in the industry feel like that cutoff is way too generous. Experienced engineers often put it at 50 lines, or even 25.

Another solid indicator: nested if statements. Some people say “deeply nested” if statements, but let’s be honest, more than one level of nesting in Bash is already getting painful. Python handles complex branching logic far more gracefully, and you’ll thank yourself when you come back to maintain it six months later.

Unit Testing Tells the Story

You can do unit testing with Bash. BATS (Bash Automated Testing System) exists, and ShellCheck is useful as a lightweight linter for catching bad practices. But despite these tools, Python’s testing ecosystem is on another level entirely. It’s fully mature with multiple frameworks, excellent mocking capabilities, and the ability to simulate network calls, external APIs, or system binaries. Complex mocking that would be difficult or impossible in Bash is straightforward in Python.

If your script needs solid testing or if it’s doing anything important, that’s a strong vote for Python.

Bash’s Biggest Win: Portability

So what does Bash actually win at? Portability. When you think about all the dependencies Python needs to run, Bash is the clear winner. You’re distributing a single .sh file. That’s it.

With Python, you have to ask: Does Python exist on this machine? Is it the right version? You’ll need a virtual environment so you don’t pollute system Python. You need third-party libraries installed via a package manager; and please friends, remember that we don’t let friends use pip. Use Poetry or uv. Pip is so bad that I’d honestly argue that Bash not having a package manager is better than Python having pip. At least Bash doesn’t pretend to manage dependencies well.

If you want something simple, something that can run on practically any Unix-based machine without setup, Bash is your answer. Even Windows can handle it these days through WSL, though you’re jumping through a few hoops.

TLDR

The decision is actually pretty straightforward:
- Use Bash when you’re gluing together system commands, the logic is linear, it’s under 50 lines, and portability matters.
- Use Python when you’re parsing structured data, need error handling, have branching logic, want proper tests, or the script is going to grow.
If you’re reaching for jq, writing nested if statements, or the script is getting long enough that you’re losing track of what it does… it’s time for Python.

I think in a future post we might look at when Go makes sense over Bash. There’s a lot to cover there about compiled binaries, but for now, hopefully this helps you make the call next time you’re wondering what to start your scripting with.
Mar 10, 2026 / DevOps / Programming / Python / Bash / Scripting

Enjoyed this?
Structured concurrency & Go

How Python and Kotlin provide structured concurrency out of the box while Go achieves the same patterns explicitly using errgroup, WaitGroup, and context.

Mar 7, 2026 / Programming / Golang / Python / links
I built a hacker terminal typing game. Type Python symbols to “decrypt” corrupted code, hex becomes assembly, then pseudocode, then real source. Mess up and the screen glitches. A typing tutor for programmers that doesn’t feel like one.

decrypt.logan.center

Feb 27, 2026 / Gaming / Programming / Python
Stop Using pip. Seriously.
If you’re writing Python in 2026, I need you to pretend that pip doesn’t exist. Use Poetry or uv instead.

Hopefully you’ve read my previous post on why testing matters. If you haven’t, go read that first. Back? Hopefully you are convinced.

If you’re writing Python, you should be writing tests, and you can’t do that properly with pip. It’s an unfortunate but true state of Python right now.

In order to write tests, you need dependencies, which is how we get to the root of the issue.

The Lock File Problem

The closest thing pip has to a lock file is pip freeze > requirements.txt. But it just doesn’t cut the mustard. It’s just a flat list of pinned versions.

A proper lock file captures the resolution graph, the full picture of how your dependencies relate to each other. It distinguishes between direct dependencies (the packages you asked for) and transitive dependencies (the packages they pulled in). A requirements.txt doesn’t do any of that.

Ok, so? You might be asking yourself.

It means that you can’t guarantee that running pip install -r requirements.txt six months or six minutes from now will give you the same copy of all your dependencies.

It’s not repeatable. It’s not deterministic. It’s not reliable.

The one constant in Code is that it changes. Without a lock file, you’re rolling the dice every time.

Everyone Else Figured This Out

Every other modern language ecosystem “solved” this problem years ago:
- JavaScript has package-lock.json (npm) and pnpm-lock.yaml(pnpm)
- Rust has Cargo.lock
- Go has go.sum
- Ruby has Gemfile.lock
- PHP has composer.lock
Python’s built-in package manager just… doesn’t have this.

That’s a real problem when you’re trying to build reproducible environments, run tests in CI, or deploy with any confidence that what you tested locally is what’s running in production.

What to Use Instead

Both Poetry and uv solve the lock file problem and give you reproducible environments. They’re more alike than different — here’s what they share:
- Lock files with full dependency resolution graphs
- Separation of dev and production dependencies
- Virtual environment management
- pyproject.toml as the single config file
- Package building and publishing to PyPI
Poetry is the more established option. It’s at version 2.3 (released January 2026), supports Python 3.10–3.14, and has been the go-to alternative to pip for years. It’s stable, well-documented, and has a large ecosystem of plugins.

uv is the newer option from Astral (the team behind Ruff). It’s written in Rust and is 10–100x faster than pip at dependency resolution. It can also manage Python versions directly, similar to mise or pyenv. It’s currently at version 0.10, so it hasn’t hit 1.0 yet, but gaining adoption fast.

You can’t go wrong with either. Pick one, use it, and stop using pip.
Feb 23, 2026 / DevOps / Programming / Python

Enjoyed this?
Switching to mise for Local Dev Tool Management
I’ve been making some changes to how I configure my local development environment, and I wanted to share what I’ve decided on.

Let me introduce to you, mise (pronounced “meez”), a tool for managing your programming language versions.

Why Not Just Use Homebrew?

Homebrew is great for installing most things, but I don’t like using it for programming language version management. It is too brittle. How many times has brew upgrade decided to switch your Python or Node version on you, breaking projects in the process? Too many, in my experience.

mise solves this elegantly. It doesn’t replace Homebrew entirely, you’ll still use that for general stuff but for managing your system programming language versions, mise is the perfect tool.

mise the Great, mise the Mighty

mise has all the features you’d expect from a version manager, plus some nice extras:

Shims support: If you want shims in your bash or zsh, mise has you covered. You’ll need to update your RC file to get them working, but once you do, you’re off to the races.

Per-project configuration: mise can work at the application directory level. You set up a mise.toml file that defines its behavior for that specific project.

Environment management: You can set up environment variables directly in the toml file, auto-configure your package manager, and even have it auto-create a virtual environment.

It can also load environment variables from a separate file if you’d rather not put them in the toml (which you probably want if you’re checking the file in).

It’s not a package manager: This is important. You still need poetry or uv for Python package management. As a reminder: don’t ever use pip. Just don’t.

A Quick Example

Here’s what a .mise.toml file looks like for a Python project:
```
[tools]
python = "3.12.1"
"aqua:astral-sh/uv" = "latest"

[env]
# uv respects this for venv location
UV_PROJECT_ENVIRONMENT = ".venv"

_.python.venv = { path = ".venv", create = true }
```
Pretty clean, right? This tells mise to use Python 3.12.1, install the latest version of uv, and automatically create a virtual environment in .venv.

Note on Poetry Support

I had to install python from source using mise to get poetry working. You will want to leave this setting to be true. There is some problem with the precompiled binaries they are using.

You can install global python packages, like poetry, with the following command:
```
mise use --global poetry@latest
```
Yes, It’s Written in Rust

The programming veterans among you may have noticed the toml configuration format and thought, “Ah, must be a Rust project.” And you’d be right. mise is written in Rust, which means it’s fast! The project is stable, has a ton of GitHub stars, and is actively maintained.

Task Runner Built-In

One feature I wasn’t expecting: mise has a built-in task runner. You can define tasks right in your mise.toml:
```
[tasks."venv:info"]
description = "Show Poetry virtualenv info"
run = "poetry env info"

[tasks.test]
description = "Run tests"
run = "poetry run pytest"
```
Then run them with mise run test or mise r venv:info.

If you’ve been putting off setting up Make for a project, this is a compelling alternative. The syntax is cleaner and you get descriptions for free

I’ll probably keep using Just for more complex build and release workflows, but for simple project tasks, mise handles it nicely. One less tool to install.

My Experience So Far

I literally just switched everything over today, and it was a smooth process. No too major so far. I’ll report back if anything breaks, but the migration from my previous setup was straightforward.

Now, I need to get the other languages I use, like Go, Rust, and PHP setup and moved to mise. Having everything consolidated into one tool is going to be so nice.

If you’re tired of Homebrew breaking your language versions or juggling multiple version managers for different languages, give mise a try.

The documentation is solid, and the learning curve is minimal.
Feb 11, 2026 / DevOps / Tools / Development / Python

Enjoyed this?
JavaScript Still Doesn't Have Types (And That's Probably Fine)
Here’s the thing about JavaScript and types: it doesn’t have them, and it probably won’t any time soon.

Back in 2022, there was a proposal to add TypeScript-like type syntax directly to JavaScript. The idea was being able to write type annotations without needing a separate compilation step. But the proposal stalled because the JavaScript community couldn’t reach consensus on implementation details.

The core concern? Performance. JavaScript is designed to be lightweight and fast, running everywhere from browsers to servers to IoT devices. Adding a type system directly into the language could slow things down, and that’s a tradeoff many aren’t willing to make.

So the industry has essentially accepted that if you want types in JavaScript, you use TypeScript. And honestly? That’s fine.

TypeScript: JavaScript’s Type System

TypeScript has become the de facto standard for typed JavaScript development. Here’s what it looks like:
```
// TypeScript Example
let name: string = "John";
let age: number = 30;
let isStudent: boolean = false;

// Function with type annotations
function greet(name: string): string {
  return `Hello, ${name}!`;
}

// Array with type annotation
let numbers: number[] = [1, 2, 3];

// Object with type annotation
let person: { name: string; age: number } = { name: "Alice", age: 25 };
```
TypeScript compiles down to plain JavaScript, so you get the benefits of static type checking during development without any runtime overhead. The types literally disappear when your code runs.

The Python Parallel

You might be interested to know that the closest parallel to this JavaScript/TypeScript situation is actually Python.

Modern Python has types, but they’re not enforced by the language itself. Instead, you use third-party tools like mypy for static analysis and pydantic for runtime validation. There’s actually a whole ecosystem of libraries supporting types in Python in various ways, which can get a bit confusing.

Here’s how Python’s type annotations look:
```
# Python Example
name: str = "John"
age: int = 30
is_student: bool = False

# Function with type annotations
def greet(name: str) -> str:
    return f"Hello, {name}!"

# List with type annotation
numbers: list[int] = [1, 2, 3]

# Dictionary with type annotation
person: dict[str, int] = {"name": "Alice", "age": 25}
```
Look familiar? The syntax is surprisingly similar to TypeScript. Both languages treat types as annotations that help developers and tools understand the code, but neither strictly enforces them at runtime (unless you add additional tooling).

What This Means for You

If you’re writing JavaScript, stop, and use TypeScript. It’s mature and widely adopted. Now also you can run TypeScript directly in some runtimes like Bun or Deno.

Type systems were originally omitted from many of these languages because the creators wanted to establish a low barrier to entry, making it significantly easier for people to adopt the language.

Additionally, computers at the time were much slower, and compiling code with rigorous type systems took a long time, so creators prioritized the speed of the development loop over strict safety.

However, with the power of modern computers, compilation speed is no longer a concern. Furthermore, the type systems themselves have improved significantly in efficiency and design.

Since performance is no longer an issue, the industry has shifted back toward using types to gain better structure and safety without the historical downsides.
Feb 2, 2026 / Programming / Python / javascript / Typescript

Enjoyed this?
Daily Dose of Data Science

A daily column with insights, observations, tutorials and best practices on python and data science. Read by industry professionals at big tech, startups, and engineering students.

Feb 1, 2026 / Python / links / tutorials
Learning to Program in 2026

If I had to start over as a programmer in 2026, what would I do differently? This question comes up more and more and with people actively building software using AI, it’s as relevant as ever.

Some people will tell you to pick a project and learn whatever language fits that project best. Others will push JavaScript because it’s everywhere and you can build just about anything with it. Both are reasonable takes, but I do think there’s a best first language.

However, don’t take my word for it. Listen to Brian Kernighan. If you’re not familiar with the name, he co-authored The C Programming Language back in 1978 and worked at Bell Labs alongside the creators of Unix. Oh also, he is a computer science Professor at Princeton. This man TAUGHT programming to generations of computer scientists.

There’s an excellent interview on Computerphile with Kernighan where he makes a compelling case for Python as the first language.

Why Python?

Kernighan makes three points that you should listen to.

First, the “no limitations” argument. Tools like Scratch are great for kids or early learners, but you hit a wall pretty quickly. Python sits in a sweet spot—it’s readable and approachable, but the ecosystem is deep enough that you won’t outgrow it.

Second, the skills transfer. Once you learn the fundamentals—loops, variables, data structures—they apply everywhere. As Kernighan puts it: “If you’ve done N programming languages, the N+1 language is usually not very hard to get off the ground.”

Learning to think in code matters more than any specific syntax.

Third, Python works great for prototyping. You can build something to figure out your algorithms and data structures, then move to another language depending on your needs.

Why Not JavaScript?

JavaScript is incredibly versatile, but it throws a lot at beginners. Asynchronous behavior, event loops, this binding, the DOM… and that’s a lot of cognitive overhead when you’re just trying to grasp what a variable is.

Python’s readable syntax lets you focus on learning how to think like a programmer. Fewer cognitive hurdles means faster progress on the fundamentals that actually matter.

There’s also the type system. JavaScript’s loose equality comparisons (== vs ===) and automatic type coercion trip people up constantly.

Python is more predictable. When you’re learning, predictable is good.

The Path Forward

So here’s how I’d approach it: start with Python and focus on the basics. Loops, variables, data structures.

Get comfortable reading and writing code. Once you’ve got that foundation, you can either go deeper with Python or branch out to whatever language suits the projects you want to build.

The goal isn’t to master Python, it’s to learn how to think about problems and express solutions in code.

That skill transfers everywhere, including reviewing AI-generated code in whatever language you end up working with.

There are a ton of great resources online to help you learn Python, but one I see consistently is Python for Everyone by Dr Chuck.

Happy coding!

Jan 21, 2026 / Programming / Python / learning

Enjoyed this?
When do you think everyone will finally agree that Python is Python 3 and not 2? I know we aren’t going to get a major version bump anytime soon, if ever again, but we really should consider putting uv in core… Python needs modern package management baked in.

Jan 16, 2026 / Programming / Python

Python

Python: setup.py Is a Remote Code Execution Primitive

Rust: The Safety Guarantees Stop at the Compiler

The Pattern Across All Three Ecosystems

Sources

Why Can’t I Just Type note?

Restructuring Your Project

Create the new directories

Move your script

Create the package marker

Update pyproject.toml

Verify the structure

Installing It For Real

One thing to know about editing

Picking a Language

A Code Editor: Zed

Install the zed Command

Set Up Your Project

Building a Note Taker

Part 3: Python Without the Mess (uv)

Create Your Project

Running Your Script

Python: Reference Counting

JavaScript (V8): Generational Garbage Collection

Go: Tricolor Mark-and-Sweep

Garbage, Collected

References

What Bash Actually Is

Where Bash Falls Short

The Performance Question

The Guidelines People Throw Around

Unit Testing Tells the Story

Bash’s Biggest Win: Portability

TLDR

The Lock File Problem

Everyone Else Figured This Out

What to Use Instead

Why Not Just Use Homebrew?

mise the Great, mise the Mighty

A Quick Example

Note on Poetry Support

Yes, It’s Written in Rust

Task Runner Built-In

My Experience So Far

TypeScript: JavaScript’s Type System

The Python Parallel

What This Means for You

Why Python?

Why Not JavaScript?

The Path Forward

Why Can’t I Just Type `note`?

Install the `zed` Command