The workshop teardown
You installed Go six months ago for a side project. The project shipped. Your machine feels cluttered, or you are switching tools, or you just want a clean slate before reinstalling a newer version. You delete the Go directory, close the terminal, and assume you are done. You are not. The shell still remembers where Go lives. Your workspace still sits in your home directory. The next time you open a new terminal window, go version still prints something. Removing Go properly means packing up the tools, clearing the workbench, and erasing the map that tells your system where everything was.
How Go actually lives on your machine
Go does not use a traditional installer that registers itself with your operating system. It does not drop files across a dozen system directories or write to a central registry. Go lives as a portable collection of files. You download an archive, extract it, and tell your shell where to look. Uninstallation is the exact reverse. You remove the files and remove the instructions that point to them.
Think of Go like a portable workshop in a box. The box contains the tools. You also have a workbench where you build things. Finally, you have a sticky note on your desk that says "The workshop is in the garage." If you throw away the box but leave the sticky note, you will keep walking to the garage looking for tools that are no longer there. Uninstalling means throwing away the box, clearing the workbench, and tearing up the sticky note.
Go treats installation as a portable archive. This design choice keeps Go simple and reproducible. The same archive works on Linux, macOS, and Windows without modification. The trade-off is that the operating system does not know Go exists until your shell configuration tells it to. Shell startup files like ~/.bashrc, ~/.zshrc, or ~/.profile contain lines that export GOROOT, GOPATH, and append $GOROOT/bin to your PATH. When you open a terminal, the shell reads those files and builds an environment. If those lines remain, the shell will keep pointing to a directory that no longer exists.
Go developers conventionally rely on go env to inspect their setup rather than guessing. Run go env GOROOT GOPATH GOMODCACHE before you delete anything. Write down the paths. Verify they match what you are about to remove. Trust the output, not your memory.
The bare minimum removal
Here is the simplest sequence for a manual installation. It removes the binaries, clears the workspace, and unsets the variables for the current session.
# Remove the directory containing the compiler, standard library, and go binary
sudo rm -rf /usr/local/go
# Remove source code, compiled binaries, and the module cache that stores downloaded dependencies
rm -rf ~/go
# Unset GOROOT and GOPATH for the current session; PATH requires editing the shell config file
unset GOROOT
unset GOPATH
Running unset only affects the terminal window you are currently using. It does not edit your configuration files. The next time you open a new window, the shell will reload the old exports and restore the variables. You need to edit the startup files to make the change permanent.
The module cache inside ~/go/pkg/mod can easily consume several gigabytes of disk space. Deleting it frees that storage immediately. The cache stores every dependency your projects ever downloaded. If you plan to reinstall Go later, you can keep the cache to avoid redownloading packages. If you want a truly clean machine, delete it. The next go build will repopulate it as needed.
Go is portable. Treat it like files, not a system service.
What happens under the hood
When you execute those commands, the filesystem deletes the directory tree. The rm -rf flag forces removal without prompting and recurses into subdirectories. The shell configuration step is where most people leave traces behind. Your shell reads startup files in a specific order. Bash reads ~/.bashrc for interactive non-login shells and ~/.profile or ~/.bash_profile for login shells. Zsh reads ~/.zshrc and ~/.zprofile. macOS switched to Zsh as the default shell in recent versions, so check ~/.zshrc if you are on a Mac. If you added Go paths to multiple files, you need to check all of them.
Open your shell configuration in a text editor. Look for lines that export GOROOT or GOPATH. Look for lines that append $GOROOT/bin or /usr/local/go/bin to PATH. Delete those lines entirely. Save the file and reload it with source ~/.bashrc or source ~/.zshrc. The shell now runs with a clean environment. Type go version and watch it fail with a command-not-found error. That failure is the goal.
Go automatically detects GOROOT when it is not set. The compiler looks for the directory containing the go binary and walks up one level. If you leave GOROOT exported but delete the directory, the compiler rejects every build with a missing standard library error. The error message points to the standard library path and stops compilation. Unsetting the variable forces Go to fall back to its automatic detection, which immediately fails in a predictable way.
The shell remembers what you told it. Edit the config, not just the files.
Cleaning up the real-world mess
Manual tarball installations are rare these days. Most developers use package managers or version managers. Those tools change where Go lives and how it registers itself. A blind rm -rf can break your package manager or leave orphaned symlinks.
Here is a verification script that checks common locations and reports what it finds. It helps you decide what to remove next.
# Check if the go binary is still accessible in PATH
which go 2>/dev/null || echo "go binary not found in PATH"
# Check for Homebrew installations on macOS
brew list --formula | grep -E "^go$|^golang$" || echo "No Homebrew Go formula found"
# Check for asdf version manager plugins
asdf list go 2>/dev/null || echo "asdf Go plugin not active or not installed"
# Display current GOROOT and GOPATH if they are still set
echo "GOROOT: $GOROOT"
echo "GOPATH: $GOPATH"
Package managers handle cleanup differently. Homebrew tracks installed formulas in its cellar. Running brew uninstall go removes the formula and cleans up the symlink in /usr/local/bin or /opt/homebrew/bin. Apt on Ubuntu uses sudo apt remove golang-go. Yum or Dnf on Fedora uses sudo dnf remove golang. Version managers like asdf or fnm store each Go version in a dedicated directory like ~/.asdf/installs/go/1.21.0. You remove a specific version with asdf uninstall go 1.21.0.
The module cache is the most common leftover. Even after you remove the Go binary, ~/go/pkg/mod stays behind. It contains every dependency your projects ever downloaded. If you plan to reinstall Go later, you can keep it to avoid redownloading packages. If you want a truly clean machine, delete it. The next go build will repopulate it as needed.
Package managers own the cleanup. Let the tool remove what it installed.
Pitfalls and silent leftovers
Deleting the wrong directory breaks more than just Go. Running sudo rm -rf /usr/local/go on a system where Homebrew installed Go to /opt/homebrew/Cellar/go does nothing. The binary remains active. Conversely, running sudo rm -rf /usr/local deletes your entire Homebrew installation and every other tool installed there. Always verify the exact path before using recursive delete.
Shell configuration files often contain commented-out lines or backup exports. A line like # export PATH=$PATH:/usr/local/go/bin is harmless. A line like export PATH=$PATH:/usr/local/go/bin is active. Search for go/bin or GOROOT across all your dotfiles. Some editors or IDEs cache the Go binary path in their own settings. VS Code stores it in go.goroot. JetBrains IDEs store it in the project SDK settings. Clear those if you want a complete teardown.
The compiler complains with go: cannot find GOROOT directory: /usr/local/go if the environment variable points to a missing path. This error stops compilation immediately. Unsetting the variables prevents that confusing state.
Long-running servers compiled with Go might stay in memory until you kill them. If you ran a binary directly, it holds resources until terminated. Check for running processes with ps aux | grep go or pgrep -f go. Terminate them before removing the binary.
Verify paths before deleting. A typo in rm -rf costs more than a reinstall.
Which removal method fits your setup
Use a package manager command when you installed Go through Homebrew, apt, dnf, or choco. Use a version manager command when you use asdf, fnm, or goenv. Use manual deletion when you extracted an official tarball or downloaded a zip archive. Use a full workspace wipe when you want to reclaim disk space from cached modules and compiled binaries. Use a targeted config edit when you only want to hide Go from your shell but keep the installation for occasional use.
Match the removal method to the installation method. Symmetry prevents leftovers.