The script works on your laptop, but crashes in production
You wrote a Python script that scrapes data from ten websites. It runs fine on your machine. You deploy it to a server to handle ten thousand requests. The memory usage spikes. The CPU hits 100 percent. The process crashes. You wrote a Node.js service. It handles requests fast until one slow database call blocks the event loop and every other request stalls. You need a language that handles scale without forcing you to manage memory manually or juggle thread pools. You need Go.
Go is a statically typed, compiled language designed for building reliable systems. It combines the speed of C with the developer experience of a scripting language. It produces a single binary that runs anywhere. It has built-in concurrency primitives that make parallel code safe and simple. The language was created at Google to solve the problems of large-scale networked systems: slow compilation, complex dependency management, and concurrency bugs.
Think of Go as a precision-engineered engine that you can build in an afternoon. Python is a Swiss Army knife; it does everything but isn't optimized for heavy lifting. Go is a dedicated tool. It strips away features that cause confusion and focuses on what works in production. The syntax is small. The standard library is huge. You rarely need third-party packages for common tasks.
How Go works
Go is compiled. You write source code, the compiler turns it into machine code, and you get a binary file. The binary contains everything it needs to run. You don't need a runtime installed on the target machine. You build on your laptop, copy the file to the server, and run it. This makes deployment trivial. You can also cross-compile. Set environment variables to target a different operating system or architecture, and the toolchain handles the heavy lifting.
Go has a garbage collector. You don't manually allocate and free memory. The runtime tracks object usage and reclaims memory automatically. The collector is optimized for low latency. It pauses the program for microseconds, not milliseconds. You get the safety of automatic memory management without the performance penalty of older garbage collectors.
Go uses static typing. The compiler checks types before the program runs. You catch errors at build time, not in production. The type system is simple. There are no generics in the old sense, though modern Go supports type parameters for collections. The focus is on readability and predictability.
package main
import "fmt"
// main is the entry point for executable programs.
func main() {
// fmt.Println writes to standard output and adds a newline.
fmt.Println("Go is running.")
}
Save this code in a file named main.go. Run go run main.go in your terminal. The command compiles the code and executes it immediately. The output is Go is running.. The package main declaration tells the compiler this file belongs to the main package, which is required for executable programs. The func main function is the entry point. The import statement brings in the fmt package for formatted I/O.
Go compiles fast. The compiler is written in Go and optimized for speed. Large projects compile in seconds. This keeps the edit-compile-run loop tight. You don't wait for builds. You iterate quickly.
Building a web service
Go shines in web services. The standard library includes a robust HTTP server. You can build a production-ready API without external dependencies. Here's a server that handles requests and logs errors.
package main
import (
"fmt"
"log"
"net/http"
)
// handleHello writes a greeting to the HTTP response.
func handleHello(w http.ResponseWriter, r *http.Request) {
// http.ResponseWriter sends data back to the client.
fmt.Fprint(w, "Hello from Go")
}
func main() {
// http.HandleFunc registers the handler for the "/" path.
http.HandleFunc("/", handleHello)
// log.Fatal prints to stderr and exits if the server fails to start.
log.Fatal(http.ListenAndServe(":8080", nil))
}
Run this with go run main.go. The server starts on port 8080. Open http://localhost:8080 in your browser. You see Hello from Go. The handleHello function is a handler. It takes a ResponseWriter to send data and a *Request to read the incoming request. The http.HandleFunc function registers the handler for the root path. http.ListenAndServe starts the server. log.Fatal prints an error and exits if the server cannot bind to the port.
This pattern is standard in Go. Handlers are functions with a specific signature. You register them with a router. The server manages connections and goroutines automatically. Each request runs in its own goroutine. You get concurrency for free.
Concurrency with goroutines
Goroutines are lightweight threads managed by the Go runtime. They cost a few kilobytes of memory. You can spawn thousands of them without crashing. The runtime schedules them across operating system threads. You don't manage thread pools. You just write concurrent code.
package main
import (
"fmt"
"sync"
)
// wg tracks the number of active goroutines.
var wg sync.WaitGroup
func worker(id int) {
// wg.Done decrements the counter when the goroutine finishes.
defer wg.Done()
fmt.Printf("Worker %d done\n", id)
}
func main() {
// wg.Add increments the counter for each goroutine we spawn.
for i := 0; i < 5; i++ {
wg.Add(1)
// The go keyword starts a new goroutine.
go worker(i)
}
// wg.Wait blocks until the counter reaches zero.
wg.Wait()
}
Run this code. You see five lines of output, one for each worker. The order might vary. Goroutines run concurrently. The sync.WaitGroup ensures the main function waits for all workers to finish. Without wg.Wait, the program exits immediately, killing the goroutines. The defer statement schedules wg.Done to run when worker returns. This guarantees the counter decrements even if the function panics.
Channels are the pipes that connect goroutines. You send values through a channel and receive them on the other side. Channels synchronize access to data. You don't need mutexes for simple communication. The rule is: don't communicate by sharing memory; share memory by communicating.
package main
import "fmt"
func main() {
// messages holds strings and allows one send before blocking.
messages := make(chan string, 1)
// This goroutine sends a value to the channel.
go func() {
messages <- "ping"
}()
// <-messages receives the value and blocks until sent.
msg := <-messages
fmt.Println(msg)
}
This code prints ping. The channel is buffered to one. The goroutine sends a value and exits. The main function receives the value. If the buffer were size zero, the send would block until the receive happens. Channels make data flow explicit. You can see where values come from and where they go.
Goroutines are cheap. Channels are not magic. Use them to coordinate work, not to replace control flow.
Pitfalls and conventions
Go has opinions. The community follows conventions that make code readable and maintainable. Breaking these conventions makes your code hard to read for other Go developers.
Error handling uses values, not exceptions. Functions return an error as the last return value. You check it immediately.
result, err := doSomething()
if err != nil {
return err
}
This looks verbose. It forces you to handle errors at the point of failure. You can't accidentally ignore an error. The compiler doesn't force you to handle it, but the community convention makes the unhappy path visible. If you forget to check an error, linters flag it. The pattern if err != nil { return err } is standard. Wrap errors with context using fmt.Errorf("context: %w", err) to preserve the error chain.
Formatting is automatic. Run gofmt on your code. It reformats everything to a standard style. Indentation, spacing, line breaks. The community agrees on formatting. It reduces cognitive load. You don't argue about style. You argue about logic. Most editors run gofmt on save. Trust the tool.
# gofmt reformats the file in place.
# Run it manually if your editor doesn't support it.
gofmt -w main.go
Interfaces are implicit. You don't declare that a struct implements an interface. If the struct has the methods, it implements the interface. This decouples code. You can write functions that accept an interface, and pass any struct that matches. The mantra is "accept interfaces, return structs". Functions take flexible inputs but return concrete types so callers know what they have.
// Reader is an interface for reading bytes.
type Reader interface {
Read(p []byte) (n int, err error)
}
// File implements Reader implicitly.
type File struct {
name string
}
// Read satisfies the Reader interface.
func (f *File) Read(p []byte) (int, error) {
return 0, nil
}
The receiver name is usually one or two letters matching the type. Use (f *File), not (this *File) or (self *File). This keeps method signatures short. Public names start with a capital letter. Private names start lowercase. There are no keywords like public or private. Capitalization controls visibility.
The underscore discards a value intentionally. result, _ := ... says "I considered the second return value and chose to drop it". Use it sparingly with errors. Dropping an error without the underscore triggers a compiler warning in some linters. The compiler rejects unused variables with declared and not used. It rejects unused imports with imported and not used. These errors keep your code clean.
Goroutine leaks happen when a goroutine waits on a channel that never gets closed. Always have a cancellation path. Use context.Context to signal cancellation. The context always goes as the first parameter, conventionally named ctx. Functions that take a context should respect cancellation and deadlines.
// doWork respects cancellation via the context.
func doWork(ctx context.Context) error {
select {
case <-ctx.Done():
return ctx.Err()
case result := <-results:
return nil
}
}
Context is plumbing. Run it through every long-lived call site.
The worst goroutine bug is the one that never logs. If a goroutine blocks forever, you won't see it in logs. Use timeouts and deadlines. Monitor goroutine counts in production.
When to use Go
Go is not the best tool for every job. Pick the right language for the problem.
Use Go when you need a high-performance service with simple deployment. Use Go when you want concurrency without the complexity of threads. Use Go when you value fast compilation and a single binary. Use Go when you are building CLI tools that need to run on many platforms. Use Go when you want a standard library that covers networking, HTTP, and cryptography without external dependencies.
Use Python when you need rapid prototyping or access to a vast ecosystem of data science libraries. Use Python when the team is more comfortable with dynamic typing and you don't need strict performance guarantees. Use Rust when you need zero-cost abstractions and fine-grained control over memory without a garbage collector. Use Rust when safety and performance are both critical and you can handle a steeper learning curve. Use JavaScript when you are building a browser-based UI or need a unified language for full-stack web development. Use JavaScript when the ecosystem of frameworks and packages solves your problem faster than writing from scratch.
Go sits in the middle. It's faster than Python and JavaScript. It's easier to write than Rust and C++. It's designed for systems that run for years, not scripts that run once. It's the language of cloud infrastructure. Docker, Kubernetes, Prometheus, Terraform, and etcd are written in Go. The ecosystem is mature. The tooling is excellent. The community is pragmatic.
Interfaces are contracts. Implement them implicitly.