You don't need virtualenv in Go - Eli Bendersky's website

Why Go doesn’t need a Python-style virtualenv

Developers switching from Python to Go often ask whether they need something like virtualenv. The short answer is no. The reasons fall into two categories: how you run your code, and how you develop it.

Running and distributing binaries

Python has multiple mutually incompatible language versions and packaging tool versions, and different programs may depend on packages with conflicting versions. Python code also typically expects to be installed, with dependencies located in a central place — a problem on systems where you lack permission to install there. Bundling tools like PyInstaller help, but virtualenv remains a popular solution.

Go sidesteps the entire problem because it compiles to a statically linked native executable with no dependency on compiler or package versions. You don’t have to install Go programs into a central location; just run the binary. Go also has strong cross-compilation support, so building for multiple operating systems from one development machine is straightforward.

Isolating dependencies during development

The development scenario for virtualenv goes something like this: your package needs foo version 1.2 or later, but your system has 0.9 installed, and upgrading breaks another program. In a real project, foo might be Django, and conflicting requirements between your code and other critical systems can make such a situation painful to resolve.

Go modules handle this cleanly. A module effectively acts as its own virtualenv: the go.mod file pins the exact versions your project needs, and those versions never mix with modules from another project that has its own go.mod.

Module directives go further. The replace directive lets you point a dependency to a local copy — useful for testing a quick patch on a package you suspect has a bug, without waiting for an upstream release. When you need to investigate issues with different Go versions, the toolchain also supports installing multiple versions side by side, each with its own standard library that won’t conflict with the others.