Go

Go and PowerShell work well together on Windows. PowerShell is convenient for orchestration, object filtering, scheduled tasks, and Windows management APIs. Go is useful when a small tool needs a single compiled executable, predictable startup behavior, or easy distribution to machines that do not have a PowerShell module installed. The useful split is simple: use PowerShell to prepare inputs, call the Go program, inspect its output, and react to its exit code. Let the Go program own the focused task it was written for. Do not make PowerShell scrape a human-oriented console screen when the Go command can return structured JSON or a clear exit code instead. ...

Go is a good place to coordinate a Windows utility that needs a compiled executable, HTTP service, queue worker, or structured application logic. PowerShell is still useful for the Windows task itself: calling a mature module, querying local configuration, or using an administrative command that already exists as a script. The reliable boundary is a PowerShell script file with named parameters, predictable standard output, useful standard error, and an explicit exit code. Let Go launch that file as a process. Do not build one large PowerShell command string from user input and hand it to -Command; nested quoting becomes fragile and command injection becomes easy to introduce. ...

Upgrading Go in WSL or Linux is usually one archive extraction, but it is easy to hide an old compiler behind PATH or accidentally accept a dependency-file rewrite while testing it. The compiler installation and the module files are separate concerns. Treat them that way and the upgrade is straightforward to test and easy to roll back. I first select the new compiler, run an existing project’s tests and build, and inspect go.mod and go.sum before deciding whether either file should change. A compiler upgrade does not, by itself, require a new module language version or a dependency cleanup. ...

Upgrading Go on a Windows workstation should be a small change, but it can become confusing when two things change at once. The installed Go compiler changes first. Then a command such as go mod tidy may propose changes to go.mod and go.sum. Those are related, but they are not the same job. I keep the first upgrade test deliberately narrow: install or select the new compiler, run the existing project’s tests and build, and inspect the module files before accepting any change. That gives a useful answer when a project fails: is this a compiler/toolchain problem, or did the dependency graph change? ...