Being Polyglot Is an Outcome, Not a Goal

When I first heard the term “polyglot developer,” I wanted to adopt it as an identity. A developer who knows multiple languages, approaches each problem with the right tool, and isn’t locked into a single ecosystem. It sounded appealing.

But looking back, that’s not how being polyglot happened for me. I didn’t set a goal and march toward it. More accurately, it went like this: a problem showed up, the tool I had at hand fell short, I learned something different. That repeated a few times. At some point I looked around and realized I knew more than one language. That’s really all there was to it.

How Go entered the picture

The Go story is concrete. In 2019 I needed to write a command-line tool. I could have written it in PHP, but I wanted to produce a self-contained binary — one that didn’t require whoever ran it to have PHP installed. I learned that Go compiles down to a single, portable executable. I tried it. It worked.

Later, when I looked into Go’s goroutine and channel model out of curiosity, I saw how cleanly the language’s concurrency approach was designed. Coming from PHP’s default single-process world, that felt quite different.

But today I don’t reach for Go when I need to write a web application. You can write an HTTP service in Go, sure — but the Laravel ecosystem is far more productive for me. I still keep Go for writing tools, small services, and anything that requires system-level interaction.

// A simple line counter in Go
package main

import (
    "bufio"
    "fmt"
    "os"
)

func countLines(path string) (int, error) {
    f, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    count := 0
    scanner := bufio.NewScanner(f)
    for scanner.Scan() {
        count++
    }
    return count, scanner.Err()
}

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintln(os.Stderr, "kullanım: satir-say <dosya>")
        os.Exit(1)
    }
    n, err := countLines(os.Args[1])
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Printf("%d satır\n", n)
}

This little tool could have been written in PHP too. But it ships as a binary — no installation required. That was my reason for choosing Go; it had nothing to do with language curiosity.

How Python entered the picture

Python came in 2020. Again, a concrete problem: pulling data from CSV files, transforming it, and saving it in different formats. I could have done it in PHP, but I found I could accomplish the same thing with far fewer lines using pandas in Python.

That’s also where I learned just how well-suited Python is for scripting. A language where you can write something quickly and run it without overthinking the details, and see the result immediately. PHP can be scripted too, but Python feels far more natural for it.

Today I use Python for data transformation, text processing, and automation scripts. I don’t choose it for writing web applications.

What it means to “know” a language

When I say I “know” more than one language, what do I actually mean? I think honesty is important here.

I’m an expert in PHP. I know the language’s nuances, the ecosystem, the patterns, and the pitfalls. That’s twelve years of accumulated knowledge.

I’m competent in Go. I can write tools, build HTTP services, and read the code. But I know I’m not an expert in Go’s deeper concurrency scenarios.

In Python, I get the job done. I write scripts, I process data. But I also know there’s a lot I’d still need to learn if I wanted to build a large application with Python.

That distinction matters. Being polyglot doesn’t mean “knowing every language to equal depth” — it means “having access to different tools for different problems.” Depth isn’t the same across every language, and it doesn’t need to be.

The trap of polyglot as a goal

Setting “learn multiple languages” as a target is a dangerous path. Deciding “I’m going to learn Rust this year” — without a real problem that actually calls for Rust — rarely gets you past a superficial acquaintance. A language only truly sinks in when you’re using it to solve a real problem.

The way I think polyglot actually happens is this: you look at a problem. The tool you have falls short, or solving it with that tool feels disproportionately costly. You look for an alternative. You find it, you learn it, you use it. After that repeats a few times, you’ve become polyglot without even noticing.

The reverse — “let me learn the language first, then I’ll find a problem for it” — usually doesn’t work. The learning stays shallow because there’s no genuine need driving it.

Looking back from today

Today I use PHP, Go, and Python. I didn’t sit down with the intention of learning all three; the problems led me to them. And each occupies a distinct space: PHP for application development, Go for tools and small services, Python for automation and data processing.

That distribution isn’t coincidence — it’s sediment. Each time you learn a new language, you start seeing the previous ones differently too. Go’s compile-time safety pushed me to take PHP’s type system more seriously. Python’s readable syntax contributed to my habit of avoiding unnecessary complexity in other languages as well.

Being polyglot is not an identity — it’s an outcome. And once you make peace with that, learning a new language settles into a healthier place: only when there’s a problem to solve, only when the time comes.