First step toward polyglot: why I started learning Go

I have been writing PHP since 2008. Eleven years. Over that time I built a fairly complete picture of what PHP can do: web applications, APIs, CLI tools, background jobs. I know the ecosystem, I know the tooling, I have internalized its pitfalls. Breaking out of that comfort zone required a deliberate decision — and I made one.

Why now? Why Go?

Recognizing the comfort of a single language

At some point I noticed something: I was solving every problem with the same tool. Regardless of the scenario, PHP + Laravel was my default answer. That habit could be called efficiency, but over time it dulls intellectual flexibility.

Learning a second language is not just about gaining another tool. When you step inside the structure of a different language, you start seeing your primary language differently too. You get the opportunity to evaluate PHP’s design decisions — or design debts — from the outside.

Why Go?

Python, Ruby, Node.js — all of them were options. I spent some time weighing them.

My concrete reasons for choosing Go:

Go is statically typed and compiled. Type declarations in PHP have grown stronger in recent years, but the dynamic nature is always there. Static types enable compile-time error detection in large codebases — I wanted to experience that.

Go’s standard library is comprehensive. Most of what you need for an HTTP server, JSON processing, and concurrency comes built into the language. Compared to reaching for an external package for everything in PHP, that difference caught my attention.

Go’s syntax is intentionally minimal. Very little abstraction, very little “magic.” The worst thing about learning a language is spending time decoding magical behavior. I am hoping Go spares me from that.

Finally: Go’s concurrency model is different. The concepts of goroutines and channels diverge fundamentally from PHP’s multi-process approach. That looks like genuinely mind-expanding territory.

What I am not expecting

I have no intention of replacing PHP with Go. Matching the maturity of the Laravel ecosystem for web applications would take years. My goal is to understand when Go is the better choice for specific problem categories — CLI tools, data-processing scripts, small services.

I also have no expectation of becoming an expert quickly. It is neither possible nor necessary to bring ten years of PHP experience up to the same level in Go. T-shaped knowledge: my depth is in PHP, and Go will represent the breadth.

What I have seen so far

The first few weeks covered go installation, basic syntax, and package structure. First surprise: err checks repeat everywhere.

package main

import (
    "fmt"
    "os"
)

func main() {
    f, err := os.Open("dosya.txt")
    if err != nil {
        fmt.Println("Hata:", err)
        return
    }
    defer f.Close()
    fmt.Println("Dosya açıldı:", f.Name())
}

Coming from exception-based error handling in PHP, this repetition feels odd. But the Go designers make it clear that this is a deliberate choice: errors are first-class citizens as values. My initial reaction was negative, but I need to write more code before I can appreciate the advantages of this approach.

Over the next few months I plan to build a small CLI tool — something that solves a real need. That is the best way to learn how a language actually feels.