I wrote PHP for about seven years before Go became my main language — Laravel for five of them, Yii2 and plain MVC before that. Then I led the rebuild of a Laravel monolith into Go microservices, and later joined a marketplace-product, to work on Go services in production. So I didn't come to Go from a tutorial. I came to it carrying a decade of PHP habits, and I had to ship real systems while unlearning them 🥲

The syntax was the easy part. You can read Go in an afternoon. What took months to rewire were the mental models — the default assumptions PHP had built into me about how a program is shaped, how errors move, how a request lives and dies. Some of those assumptions are actively wrong in Go, and they don't announce themselves 😫. They show up as code that compiles, passes review on a tired day, and then behaves in a way you didn't predict 😳

This is a list of the ones that took me longest. Each is tied to something I actually built, not a textbook example.

1. There is no try/catch, and that is a feature, not a missing one

In PHP I threw exceptions and caught them somewhere up the stack — often far up the stack, in a global handler that turned anything unexpected into a 500. The mental model is: errors travel invisibly until someone decides to look. Most of my code didn't think about failure at all; failure was something that happened to the call stack, above me.

Go inverts this. A function that can fail returns an error as its last value, and you, the caller, deal with it right there 🥳:

user, err := repo.FindUser(ctx, id)
if err != nil {
    return fmt.Errorf("find user %d: %w", id, err)
}

My first instinct was that this was noise. Coming from try { ... } catch (\Throwable $e) {}, the if err != nil after every call felt like ceremony 😅. It took me a while — and a few production incidents — to understand what it buys you: failure becomes part of the visible control flow. You can't not see that a call can fail, because the error is sitting in a variable in front of you. The decision "swallow this, retry this, or pass it up" is made at the exact place that has the most context to make it.

The habit that took longest to kill was the urge to build a catch-all. In PHP I leaned on the global exception handler. In Go I had to learn to wrap errors with context as they go up (%w and a short message at each layer) so that by the time an error reaches the top, the message is a breadcrumb trail — "find user 42: query timeout: ..." — instead of a stack trace I have to decode 🥳

This paid off in a real incident. An order wouldn't create, and the wrapped error that came out the top read essentially like this:

create order 8842: charge payment: gateway timeout after 5s

That one line pointed straight at the cause — a downstream service we were calling to charge the payment was misbehaving and timing out. No log spelunking, no guessing which layer failed. The message had assembled itself from each layer adding a little context on the way up, and by the time it reached me it told me exactly where to look. In my PHP days that would have surfaced as a generic 500 and a stack trace I'd have to read backwards 🥲

What I'd tell a PHP developer: stop looking for try/catch. The if err != nil is your error handling, and writing it everywhere forces you to actually think about each failure instead of deferring all of them to one handler that prints "Something went wrong." 👍

2. The request is not the unit of life anymore

This was the deepest shift, and the one I underestimated most.

In PHP, the model is shared-nothing per request. A request comes in, the framework boots, you handle it, the process tears everything down, and the next request starts from a clean slate. Memory leaks barely matter — the worst case is one request. Global state is reset for you. You almost never think about two requests touching the same variable, because in the classic PHP model they physically can't; they're separate processes 🙂

Go is the opposite. The process is long-lived. One Go binary stays up and handles thousands of requests concurrently, in the same memory, often literally at the same time across goroutines. The moment I internalized that, a whole category of bugs I'd never had to think about became something I had to actively watch for:

• A package-level variable is now shared across every concurrent request. In PHP that was a per-request convenience. In Go it's a data race waiting to happen.
• A map written to by two requests at once will crash the whole process — not the one request, the whole binary. The PHP blast radius of "one bad request" doesn't exist; a panic from a concurrent map write can take down everything in flight 😢
• Resources you open have to be closed deliberately, because nothing is tearing the world down after each request to clean up after you.

None of those are exotic. They're the baseline things you now have to keep in your head on every change, because the language and the runtime won't reset the world for you between requests the way PHP did. The point isn't a specific disaster — it's that a whole class of failure that was simply impossible in the per-request PHP model is now possible by default, and avoiding it is on you 🧐

Rewiring this meant changing my default question. In PHP I asked "what does this request need?" In Go I had to ask "what happens when a thousand of these run at once, in the same memory?" That question is now automatic, but it took real production exposure to make it automatic.

3. Concurrency is in the language, so you own correctness

PHP's concurrency story, for most of my career, was "use a queue and more workers." Parallelism lived outside the language — in the infrastructure, in separate processes, in something like a job queue. I rarely reasoned about two things touching the same data in the same memory, for the same reason as above: they usually couldn't.

Go puts concurrency in my hands directly. go someFunc() starts a goroutine 👍. Channels pass data between them 👍. It's genuinely powerful, and it's the reason Go fit the kind of services we were building 🥳. But the power comes with ownership: the language hands you concurrency and then holds you responsible for correctness. A goroutine that writes to a shared structure without coordination is a bug that may pass every test on your machine and only surface under real load 🥲.

Two specific habits I had to build that PHP never required:

• Reach for the race detector early. In my own projects I run tests with -race, and it's caught real races a few times now — races I'd never have spotted by reading the code, because they only show up when goroutines happen to interleave the wrong way at run time 🙏. In PHP I never had a tool like that, because I never had the problem.
• Decide deliberately how goroutines share data — pass copies, use a channel, or protect shared state with a mutex — instead of just sharing a variable because it's in scope. "It's in scope so I'll use it" is a perfectly safe PHP habit and a dangerous Go one ☝️

The mental shift: in PHP, concurrency was an infrastructure concern I delegated. In Go, it's a code concern I own line by line.

4. context.Context is the spine, not a parameter you tolerate

When I first saw ctx context.Context as the first argument of seemingly every function, I treated it the way I'd treated similar things in PHP frameworks — boilerplate to thread through and otherwise ignore. That was wrong, and it cost me before it clicked 😅.

In PHP, the request was bounded for me. When the client disconnected or the request finished, the process ended; I never had to manually propagate "this work should stop now." In a long-lived Go service, nothing stops your work automatically. If a client gives up, or a request times out, the goroutines doing the work for that request will happily keep running — querying the database, calling other services — for no one. context.Context is how cancellation and deadlines travel down through every call so that work can actually be stopped and resources released.

Once I understood it as the cancellation and deadline spine of the request, passing ctx everywhere stopped feeling like boilerplate and started feeling like the thing that keeps a long-lived service from leaking work 🙌. In a marketplace with a lot of concurrent traffic, "stop doing work nobody is waiting for" is not a nicety; it's how the service stays healthy under load.

A concrete way I use it: when I call another service, I put a deadline on the context — lets say around 5 seconds. If that downstream call runs past the deadline, the context fires, I stop waiting, and I return a clean degraded response to the client — something like "we can't process this right now, please try again in a few minutes" 🤔 — instead of leaving the request hanging forever and tying up resources behind it. That's the whole point of the spine: the deadline travels down with the call, and when it expires everyone downstream can give up together. Under load, failing fast and politely is far better than hanging, and context.Context is what makes that possible without threading a timeout flag through every function by hand 👌

5. Composition over inheritance — and Laravel had hidden how much I leaned on inheritance

This one was subtle because I didn't realize how much of my PHP design instinct was inheritance-shaped until Go took the option away 😎

In Laravel, so much is built on extending base classes — your controllers, your models, your form requests all inherit a large amount of behavior from the framework. The "right" way to add capability was often "extend the base class." That instinct is invisible while you have it; it just feels like how code is organized.

Go has no class inheritance (in usual meaning). It has struct embedding and, more importantly, interfaces that are satisfied implicitly — a type implements an interface just by having the right methods, with no implements keyword and no declared relationship. Coming from PHP's explicit class Foo extends Bar implements Baz, implicit interfaces felt almost too loose at first. Where's the contract? Who guarantees it? 🤯

What rewired it for me was using this pattern consistently at the marketplace-project. There, I define interfaces at the consumer for repositories, for internal services, and for external services — a small interface declared where it's used, and any type with the right methods satisfies it. The consumer declares only the handful of methods it actually needs; the provider doesn't have to know the interface exists. That's a very different shape from "everyone extends the framework's base class," and it produces code where dependencies are small and swapping an implementation is trivial — a real database behind a repository in production, a fake satisfying the same interface in a test. Writing tests stopped requiring a whole framework's worth of scaffolding and started being a matter of passing in a small fake that fits the interface 🥳

Coming to that from years of Laravel's extends-everything instinct is exactly why I can feel how different it is. A developer who only ever wrote Go might take implicit interfaces for granted; I had to consciously give up the inheritance reflex to get there.

6. Explicit beats clever, and the language enforces it

PHP let me be clever. Dynamic typing, magic methods, arrays that were lists and maps and objects depending on my mood — a lot of expressiveness, and a lot of rope. I wrote some clever PHP I was proud of and later could not fully reconstruct why it worked 😅

Go is deliberately boring in a way that annoyed me at first and that I now value. No magic methods. No implicit type juggling. The compiler refuses unused variables and unused imports. The formatting is not up for debate — gofmt decides, and the entire community's code looks the same. Coming from PHP's freedom, this felt like the language not trusting me 🤔

The reframe: Go optimizes for the code being read, not the code being written. On a team — and I was leading one through the rebuild, plus interviewing developers now — that tradeoff is obviously correct. Clever PHP is a liability the moment someone other than its author has to maintain it. Boring, explicit, uniformly-formatted Go is something a teammate can read at 2am during an incident and actually understand. The language took away cleverness, and what I got back - a code that my team could understand about the same way I do 😎

That, more than any single feature, is the mental model I'd most want a PHP developer to adopt before they write a line of Go: you are not writing for the interpreter's flexibility anymore. You are writing for the next person who reads it, and the language is going to hold you to that whether you like it or not 🧐

What I'd actually tell someone making this move

The syntax will take you a week. The mental models took me months, because the hard part isn't learning Go — it's unlearning the PHP assumptions that are so deep you don't know they're assumptions.

None of this is a complaint about PHP. Seven years of PHP is exactly what made the Laravel-to-Go migration something I could lead rather than just attend — I understood the system we were leaving as deeply as the one we were building. But the move only worked once I stopped writing Go in PHP's syntax and started actually thinking in Go.