Go

Depth: working, and no longer a side interest. I came from the frontend; Go is how I’m moving toward being a backend engineer who happens to be good at UI, instead of a frontend engineer who dabbles. The move stopped being theoretical when the backend became part of my job.

Where it’s real: dona.uz

At dona.uz  I’m not picking the language for a toy. It’s a live-shopping marketplace — sellers broadcasting, buyers ordering mid-stream — so the backend carries streams, orders and payments at the same time, and I’m learning Go against that instead of against exercises.

Working across the whole thing helps more than I expected: I build the mobile app, the seller panel and the services behind them, so when an endpoint is awkward I’m usually the one who also feels it on the client. That loop — design it, then have to consume it the next day — has taught me more about API design than any style guide.

What production keeps teaching me that tutorials didn’t:

• errors are a design surface, not an afterthought,
• context cancellation matters the moment a request can outlive its client,
• the boring solution survives the on-call rotation.

Why Go

Because I wanted a language where the boring answer is usually the right one: one binary, one way to format, a standard library that already has the HTTP server. After years of node_modules, that feels like fresh air.

The community half

I chair Gopher Uzbekistan under FLOSS Uzbekistan :

• founded and maintain gopher.uz  — a home for Go developers in Uzbekistan,
• moderate the Telegram community ,
• organise events, workshops and content around the Go ecosystem.

Running a community is its own skill, and it teaches the language too: nothing exposes a shaky mental model faster than a room full of people asking “but why?”.

What I’m comfortable with

• net/http services, routing, middleware, graceful shutdown.
• Goroutines, channels, context cancellation — and knowing when a mutex is the simpler answer.
• Errors as values: wrapping with %w, errors.Is / errors.As.
• go test with table-driven tests, go vet, profiling basics.

Still learning

• Larger project layout without cargo-culting somebody’s internal/ tree.
• Database access patterns I’d actually defend (sqlc, pgx) over an ORM habit imported from the JS world.
• Generics in real code, not in blog examples.

Related: TypeScript, Me.