You've got the syntax down, but writing code in an editor is only half the battle. To actually use Go, you need to get comfortable with the go command-line tool. It's not just a compiler; it's a build system, a formatter, and a package manager all rolled into one. Instead of listing commands, let's just build something and see where the tool helps us out.

I've put together a simple utility called wordcount. It takes a filename as an argument and tells you how many words are in it. Right now, it's just a file called main.go in a folder on my desktop.

Wait, where did the executable go?

When I'm just sketching out logic, I don't want to deal with managing binary files. I just want to see if my logic works. So, I'll try this:

go run main.go

It works! I see the word count in my terminal. But here's the thing: I look in my folder, and there is no wordcount executable. I'm a bit confused—did it just run in memory? Exactly. go run compiles your code to a temporary directory and executes it immediately. It's great for rapid prototyping, but if you're handing this tool to a teammate, you can't just send them a .go file and expect them to have the Go toolchain installed.

I need a real binary. Let's try go build:

go build main.go

Now, when I check my directory, there it is: a file named main (or main.exe on Windows). I can move this file to any other machine with the same OS, and it'll run without Go being installed. One detail though—since I passed the filename main.go, Go named the binary main. That's not very descriptive. If I run go build without specifying the filename while inside a module, Go uses the module's name. Much cleaner.

Cleaning up my mess

I'll be honest: I tend to get sloppy with my indentation when I'm in "flow state." My wordcount code currently has a mix of tabs and spaces, and some weirdly placed curly braces. It's ugly. In other languages, we'd spend an hour arguing about Prettier or ESLint configurations. In Go, we just do this:

go fmt main.go

I didn't see any output in the terminal, but when I jump back into my editor, the code has shifted. It's perfectly aligned. go fmt is opinionated and non-negotiable; it ensures that every Go project looks the same, regardless of who wrote it. I've stopped fighting it and just run it instinctively before every commit.

Making it a global tool

Right now, to run my wordcount tool, I have to be in the specific folder where the binary lives, or I have to type the full path. That's annoying. I want to be able to type wordcount from any directory in my terminal and have it just work.

I'll try go install:

go install

Again, nothing seems to happen in the current folder. No binary appeared. But if I move to a completely different directory—say, my home folder—and type wordcount, it runs. What happened? go install compiles the binary and moves it into a specific folder in your GOPATH (usually ~/go/bin). As long as that folder is in your system's PATH environment variable, your Go programs become global commands on your machine.

• go run: Quick check. No permanent binary.
• go build: Creates a local binary for distribution.
• go fmt: Fixes your messy formatting automatically.
• go install: Puts the binary in your Go bin folder for global access.

📋 Practical Task

Building and Installing a Global Directory-Size Calculator

Your task is to move beyond go run and integrate a tool into your system's environment. Create a small program called dirsize that prints the current working directory's path and a hardcoded string saying "Calculating size..." (you don't need to implement the actual size logic, just the CLI structure).

Requirements:

• Initialize a module named dirsize using go mod init dirsize.
• Write the code in main.go.
• Use go fmt to ensure your code meets the official Go standards.
• Use go install to install the tool globally.
• Verify the installation by opening a new terminal window, navigating to a completely different folder, and executing the dirsize command.