Hey, dipshit. You know what compiles in two seconds, deploys as a single binary, and doesn't shit itself when a transitive dependency gets yanked from npm at 3am? Go. The same way HTML has been sitting there since the dawn of the goddamn internet waiting for you to stop overcomplicating the frontend, Go has been sitting there for over a decade waiting for you to stop overcomplicating the backend.

But no. You're out there gluing together fifteen Node packages, three TypeScript build tools, and a Kubernetes cluster to serve a fucking form. You hired a Platform Team to babysit your Rails monolith. You convinced your CTO that Rust was necessary for a CRUD app that does maybe forty requests a second. Congratulations, asshole. You played yourself.

The language is boring on purpose

You know why Go feels boring? Because it is, and that's the goddamn point. There are no decorators. No metaclasses. No macros. No traits, monads, or whatever cursed abstraction the Haskell crowd is huffing this week. There are structs, functions, interfaces, goroutines, and channels. That's it. You can read the spec on a lunch break and be productive that afternoon.

Boring means the junior you hired last month can read the code the principal wrote two years ago. There's exactly one way to format it and gofmt already did it. Your "clever" coworker can't sneak a seventeen-layer abstraction into the codebase because the language won't let him. That's what shipping looks like when nobody is drooling over their own cleverness.

The standard library is the framework

Stop looking for a framework, you absolute walnut.

The standard library is the framework.

package main

import (
    "embed"
    "html/template"
    "net/http"
)

//go:embed templates/*.html
var files embed.FS

var tmpl = template.Must(template.ParseFS(files, "templates/*.html"))

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        tmpl.ExecuteTemplate(w, "index.html", map[string]string{
            "Name": "asshole",
        })
    })

    http.ListenAndServe(":8080", nil)
}

That's a working web app. HTML templates compiled into the binary. No webpack. No Vite. No "dev server". No node_modules the size of a fucking Volkswagen. You go build and you ship one file. Drop it on a server. Done.

You want a database? database/sql. JSON? encoding/json. Want to talk to another service? net/http is also a client. Want to do five things at once? Slap go in front of it. Tests? go test. Benchmarks? go test -bench. A profile? pprof is already there laughing at your console.log debugging.

The stdlib is also fucking deep

io.Reader and io.Writer are two interfaces with one method each. They are also the reason you can pipe an HTTP response body into a gzip writer into a file on disk in three lines without thinking about it. Every serious package in the ecosystem speaks them. Once you grok that, half of Go's "magic" turns out to be the same two interfaces showing up everywhere.

context.Context is how you cancel things. A user closes the browser tab, the request context cancels, the database query cancels, the downstream HTTP call cancels. All the way down. No leaked goroutines. No zombie queries chewing through your connection pool. You pass it as the first argument and you respect it. That's the whole API.

encoding/json, encoding/xml, encoding/csv, encoding/binary, all in the stdlib. Same struct tag pattern. Same decode-into-a-pointer ergonomics. Learn one and you basically know them all.

Concurrency that doesn't make you cry

Goroutines are not threads. They are stackful, multiplexed onto OS threads by the runtime, and they cost about 2KB to start. You can spawn a hundred thousand of them on a laptop. Try that with your Node event loop and watch it shit the bed.

Channels are typed pipes between goroutines. You send on one end, you receive on the other, and the runtime handles the synchronization. If you need shared state instead, sync.Mutex is right there, and the race detector will tell you when you screwed up.

results := make(chan string, len(urls))
for _, url := range urls {
    go func(u string) {
        resp, _ := http.Get(u)
        results <- resp.Status
    }(url)
}
for range urls {
    fmt.Println(<-results)
}

That's a parallel HTTP fetcher. No library, no framework, no async/await ceremony. The language does it.

A real example, not a hello-world

Here's a CRUD route reading from Postgres and rendering HTML. The whole thing.

//go:embed templates/*.html
var tmplFS embed.FS

var tmpl = template.Must(template.ParseFS(tmplFS, "templates/*.html"))

type Post struct {
    ID    int
    Title string
    Body  string
}

func postsHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        rows, err := db.QueryContext(r.Context(),
            "SELECT id, title, body FROM posts ORDER BY id DESC LIMIT 50")
        if err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        defer rows.Close()

        var posts []Post
        for rows.Next() {
            var p Post
            if err := rows.Scan(&p.ID, &p.Title, &p.Body); err != nil {
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
            }
            posts = append(posts, p)
        }

        tmpl.ExecuteTemplate(w, "posts.html", posts)
    }
}

Database, templates, and an HTTP handler in one screen. Request context wired through to the query so a closed connection cancels the SQL. No ORM, no DI container, no service layer, no controllers/ directory with seventeen abstract base classes. You can read it top to bottom and know exactly what it does.

Dependencies that don't ruin your weekend

go mod init. Done. Your dependencies live in go.mod and go.sum. The sum file is a cryptographic record of what you actually got, so you can tell when somebody pulls a left-pad on you. There is no node_modules directory. There is no lockfile drift between dev and CI. There are no peer dependencies, no optional dependencies, no devDependencies, no peerDependenciesMeta. There is one file that lists what you use, and one file that proves you got what you expected.

You want offline builds? go mod vendor drops everything into a vendor/ directory and the toolchain uses it automatically. The whole project, dependencies and all, fits in a tarball. Your security team will weep with gratitude.

The tooling ships with the compiler

gofmt formats your code. There is no debate. There is no .prettierrc holy war. The format is the format and everyone uses it. Your diffs stay small because nobody is rearranging whitespace.

go vet catches the obvious mistakes. go test runs your tests. go test -race runs them with the race detector and finds the data races you thought you didn't have. go test -bench runs benchmarks. go test -cover tells you what you missed. go tool pprof gives you flame graphs of CPU and memory usage from a running production service through an HTTP endpoint you wire up in two lines.

None of this is third-party, none of it is a plugin, and none of it requires a config file you have to maintain. It's in the box.

Deployment is a copy command

This is the part that makes Rails and Node people physically angry. You build a Go binary. You copy it to a server. You run it.

GOOS=linux GOARCH=amd64 go build -o myapp ./cmd/myapp
scp myapp user@server:/usr/local/bin/
ssh user@server 'systemctl restart myapp'

Three commands. Done. No Dockerfile. No multi-stage build. No base image CVE alerts every Tuesday. No Kubernetes manifest. No Helm chart. No ArgoCD. No service mesh. No sidecar.

A 12MB statically linked binary and a 20-line systemd unit file is a production deployment. It will outlive your career. The only reason to reach for Docker is if your ops team is contractually required to use it, and even then you can shove the binary into a FROM scratch image and call it a day.

"But what about Rails / Django / Express / Next?"

What about them? Rails needs a deploy ritual involving Capistrano, three config files, and a goat. Django wants you to learn its ORM, its admin, its middleware system, and its opinions about everything. Express is held together with npm audit warnings and prayers. Next.js changes its routing conventions every six months and gaslights you about it.

Your Go binary doesn't care. It compiled and it runs, and it'll still run in five years on hardware that doesn't exist yet. Your framework? Deprecated by Christmas, and the maintainer will write a Medium post about burnout.

"But microservices!"

No.

Write the fucking monolith. One Go binary. One Postgres. One Redis if you absolutely must. Serve HTML on the same port that serves your JSON API. Run it on a single VPS that costs less than your monthly oat milk budget. Scale that to ten thousand requests per second without breaking a sweat because Go was literally designed for this and goroutines are cheap as hell.

When you actually need to split it up, and you won't, splitting a Go monolith is just moving packages into their own repos. The interfaces are already there. You designed for it without trying because the language made you.

"But generics! But error handling! But no exceptions!"

if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. Your try/catch nesting hellscape doesn't make errors disappear, it just hides them until production at 2am.

Generics landed in 1.18. They're fine. Use them when you need them. Stop whining.

Just fucking use Go

Stop pretending you need a framework. You don't need microservices either, or a Rust rewrite, or whatever JavaScript meta-framework launched last Tuesday that's going to save you when the last six didn't.

Open your editor. Run go mod init, write a main.go, embed your templates, and compile. Ship the damn thing.

The boring choice is the right choice. It always was.