# Go developer — the language of performance and resilience > What I build in Go — microservices, queue consumers, HTTP APIs and command-line tools, and why I pick Go for that kind of work. - Technologies: Cobra, go-git, Goreleaser, Gin, Fiber - Experience: Since 2018 - Posts: 19 - Projects: 4 - Updated: 2026-09-02 - Source: https://www.muhammetsafak.com.tr/en/expertise/go/ - Language: en-US - Author: Muhammet Şafak --- ## Me in the Go ecosystem Go is not an alternative to another language for me; it is the answer to a particular class of problem. When a service or a tool has to need no installation on the other end, stay up for a long time and run cheap, this is where I start. I pick the language for the problem, not because I like it. System design itself, with its costs, is written on [sade.dev](https://sade.dev). ### What I build in Go What they have in common: processes with one job, staying up for a long time, running cheap. - **Microservices** — Services with a single responsibility, scaled on their own and deployed separately. - **Consumers and workers** — Background processes chewing through a queue for days without a break. - **HTTP APIs** — Services feeding web and mobile at once — the standard library first, Gin or Fiber when it is not enough. - **Command-line tools** — Programs shipped as a single file, needing no installation on the other end. ### Why Go 1. **A single file** — go build produces one executable. Nothing has to be installed alongside it on the other end — no interpreter, no dependency directory, whether that end is a server, a container image or someone else's machine. 2. **Cross-platform** — The same source compiles for Linux, macOS and Windows in one command. The code does not change when the target does. 3. **Concurrency inside the language** — The goroutine and channel model lets me write a consumer that runs in parallel without handing that job to a third-party library. 4. **Predictability** — Plain syntax and explicit error handling make life easier for whoever reads the code six months later — usually the team taking the work over. ### I do not pull a package for what the standard library covers Work written in Go usually outlives the day it was written, and what makes that possible is not the language alone but a dependency list kept short. Every dependency is a surface somebody will have to look after later; a structure that hides behaviour is a debt of the same class. ### Delivery is the other half Writing the service or the tool is half of it; without the second half, what you wrote only runs on your own machine. On the Go side I set up that second half too. - **Cross-compilation** — Output for three targets from the same source — Linux, macOS, Windows. - **Embedded version** — Version information goes into the binary at build time via ldflags. - **Signed output** — The shipped binary is signed, so the other end can verify what it downloaded. - **An install path** — Installing is not a download step but a single command through a package manager. ### The other end of the tool The person using the tool is usually not the person who wrote it, and I build the surface accordingly. - **A command tree that reads clearly** — What a command does should be clear from its name, without opening the help text. - **Flags that behave predictably** — The same flag means the same thing in every command; surprising behaviour is a class of bug. - **Errors that say what to do** — The message says not only what went wrong but what the user should do next. The same measure applies on the service side. ### Go is not the language for every job For a product that wants heavy business rules, a mature admin panel or a broad package ecosystem, PHP and Laravel still get there faster. I pick the language for the problem, not because I like it — the real cost of polyglot work is not learning a language, it is switching context. ## Frequently asked ### How long have you used Go? Since 2018, so 8 years. All of it alongside PHP: Go never replaced a language for me, it stands as the answer to one class of problem. ### Why did you learn Go? Being polyglot was never the goal; I simply did not have the right answer for a particular class of problem. Go is statically typed, it compiles, its standard library is broad and its syntax is deliberately plain. I never intended to swap PHP out for it — my depth stayed there, and Go came to represent breadth. ### What do you build in Go? Microservices, queue-consuming consumers and workers, HTTP APIs and command-line tools. What they have in common: processes with one job, staying up for a long time, running cheap. This site carries 19 Go-tagged posts. ### Do you write web services, or only CLIs? Both. For HTTP I start with the standard library; `net/http` is usually enough to put an API into production. Gin or Fiber comes in when I need a middleware chain, route grouping or ready-made binding. ### What do you do on the delivery side? Half the job sits there. Cross-compilation, embedding the version into the binary via ldflags, signed output and an install path — without those, what you wrote only runs on your own machine. ### How do you switch between Go and PHP? It has a cost, and I wrote it down: the real price of a polyglot codebase is not learning a language, it is switching context. On days when both are open at once, my error rate goes up. ### How many projects use Go? 4 of the projects recorded here involve Go: some end to end, others on the service or SDK side.