Why I Am Writing This: A PHP Developer Crossing Into Go
I am a PHP developer.
I have shipped Laravel and Symfony services in production...
For further actions, you may consider blocking this person and/or reporting abuse
Great post! 🙌 As a 14-year-old who just launched his first project (ClashMash - a voting battle platform), I really appreciate insights like these. Quick question: what advice would you give to someone who's just starting out with zero followers?
Just read your ClashMash write-up. A voting-battle platform shipped in 2 days with Claude, at 14, from Baku, with zero budget? That's genuinely awesome. 🙌
The "Cats vs Dogs / iOS vs Android" framing is a great hook too.
On the "zero followers" question... Forget about it at least for now! Post your thoughts and technical skills here regularly, at least once a week! And most importantly, comment on other relevant posts, and you’ll gain thousands of followers over time.
Followers are a side effect, not the goal. Chase useful and consistent, and they show up on their own. And you're already doing the two things that matter most. You built in public and shared the story. That post is the growth engine, people follow the builder way before they care about the product. Keep writing them: the next battle you add, the bug that ate your afternoon, what Claude got wrong and how you fixed it. You asked for brutally honest feedback. That's exactly right. The fastest way to get a following is to be genuinely useful in other people's spaces first, vote in their projects, leave real comments, help someone unstuck. Give before you ask.
At 14, time is your biggest unfair advantage. Keep shipping and the audience follows the work. 🚀
Nice roadmap! I like that it focuses on building real projects instead of getting stuck in theory. One question: do you think it's worth learning Go's internals (scheduler, GC, memory model) early on, or is it better to wait until you're already comfortable building production services?
Glad the focus on building landed with you. My honest take is lean later, but not never. Early on a shallow model is plenty: goroutines are cheap and the GC handles itself, so mostly you shouldn't fight it. The internals only click once you have real code to hang them on. The concurrency and profiling stretch (weeks 9 to 12 in the roadmap) is where the scheduler, escape analysis, and GC behavior stop being trivia and start explaining something you're seeing in an actual profile. Reading about GC pauses before you've allocated anything for real just won't stick. So build first, then let a concrete problem pull you into the internals. That's when they make sense and you actually remember them.
That makes sense, thanks! Do you have any favorite resources for learning Go profiling once you reach that stage, or do you think the official docs are the best place to start?
The official docs are a fine reference, but I wouldn't start there. Easiest path is to just turn on net/http/pprof in a service you've built, put it under a little load, and poke at the flame graph with go tool pprof -http=:8080 until the hot path jumps out. For something more structured, Dave Cheney's High Performance Go Workshop is the one I point people to, and it's free. Learn it on your own code, keep the docs open as reference.
As a Python person who's tried — and failed — to switch to Go at least twice 😂 this article is giving me 'maybe third time's the charm' energy. The testing section alone (table-driven tests + httptest + fuzzing, all built-in) is something Python can't touch without pulling in three dependencies. Also — dark thought: in the age of AI codegen, how many people are even gonna bother learning a new language from scratch anymore? Feels like a dying art. Glad you're keeping it alive with guides like this.
Third time's the charm and honestly the AI angle is exactly why it might stick this time. When syntax is cheap to generate, the thing that actually matters is knowing whether the code you got back is idiomatic and safe. AI will happily hand you a goroutine that leaks or a channel that deadlocks, and you won't catch it unless you understand the model. So I'd flip the dark thought: codegen doesn't kill the reason to learn Go, it raises the bar for the people who do. The syntax is the part you can outsource, the judgment isn't.
And yeah, the built-in testing story is one of my favorite parts. table-driven + httptest + fuzzing with zero deps still feels like a cheat code coming from heavier ecosystems. Go give it that third try 🙂
Alright, you might have just convinced me to give it a third try 😂 'Syntax you can outsource, judgment you can't' — that's going straight into the notebook. Any advice for someone coming from Python rather than PHP? Same roadmap work or different entry point?
Third try's the charm 😄 The roadmap works the same coming from Python, just read that Laravel vs Go table as Django/FastAPI vs Go. The one real adjustment for us is errors as values instead of try/except, and goroutines feeling great after the GIL (just don't map async/await onto them). Lean a bit harder on the foundations and CLI stage before HTTP and you're set.
Appreciate the advice 🙌 See you on the third try
the php as the cheap stack point lands differently when you've delayed the same move. the economic honesty is what most roadmap articles skip
Exactly! the move gets delayed because PHP keeps being good enough. It's never the emergency that forces your hand, it's the slow tax you stop noticing. the switch is cheap; staying is what compounds. glad the economic honesty part landed. That's the piece most roadmaps skip because it's uncomfortable to say out loud.
yeah "slow tax" is sharper than what i said. that's the one - you can't invoice the friction, so it never makes the roadmap.
Really enjoyed this! I appreciate that you explained why Go feels different instead of just listing language features.
Definitely saving this for when I start learning Go. Thanks for sharing!
Thanks, glad the "why" resonated. That mental shift is the hard part, the syntax comes fast after. Good luck when you dive in!
Great roadmap. A few topics I'd add to round out the senior Go picture:
This is probably already a plan for a new post 😃
I have long intended to learn GoLang, but I lacked the motivation. I now feel prepared to transition from the JS/TS ecosystem and explore a new programming language.
Thanks brother ❤️
Love this! JS/TS is actually a great launchpad for Go. You already know async and types, so the main shift is just errors-as-values instead of try/catch and goroutines instead of Promises. Start with the Tour of Go, build one CLI tool, and it'll click fast.
Go enjoy it, brother ❤️
Thanks! That's very informative! I'd also add what to look out for after studying Go in detail.
I was planning to add more, but I was afraid it would all turn into some kind of lengthy technical documentation 🙂
Saved this for the near future 😀
me too man ;)
It's funny, but I just realized there's a "Save" button on the left. 😂😂😂
Great article! I really like how you turned learning Go into a practical roadmap instead of just listing resources. Thanks for sharing such a clear and useful guide!
Thanks! The roadmap framing came from my own frustration with resource lists, having an order and a goal makes all the difference when picking up Go.
Es ist zwar ein langer Text, aber auf jeden Fall lesenswert! Danke fürs Teilen!
Thanks! It's long, but it's built so you can jump straight to the 12-week roadmap (or the "few days" quick track near the end) and treat the rest as reference whenever something feels foreign. Glad it was worth the read!
Oh... I guess it's time to give it a try 😄! Thanks Nazar!
Always welcome, man!
Great roadmap! What I especially liked is that you emphasize learning Go's engineering culture rather than just its syntax. One thing I'd be curious about is where you'd introduce Go's memory model and escape analysis. Not as deep compiler theory, but enough to explain why pointer vs. value receivers, allocations, and goroutines behave the way they do. It feels like understanding those concepts early helps developers write more idiomatic Go instead of accidentally bringing patterns from Java or PHP. Have you found that topic is better left until after someone has built a couple of real projects?
Thanks! This is honestly the part of the roadmap I went back and forth on the most.
Where I've landed is to split it into two layers that get taught at very different times.
The thin mental model goes early, right next to pointer vs value receivers in weeks 1-2. Not escape analysis, just one idea: a value receiver copies, a pointer receiver shares, and "escaping" means a value has to outlive the function that created it. That one sentence is usually enough to stop someone coming from Java or PHP from reflexively slapping a pointer on everything "to be safe" which is exactly the imported habit that produces the worst Go. You don't need the compiler to teach that. You need a picture in your head.
The real version is go build -gcflags="-m", -benchmem, pprof, GC pacing I leave until after a couple of real projects, and I think that's the right call. Escape-analysis output is mostly noise until you have actual allocations to stare at and a profile that's genuinely slow. Run -m on toy code on day three and all you learn is that the flag exists. You can't really motivate "why did this escape?" until you've watched a hot loop burn CPU in mallocgc. So the order I like is: feel it first, then explain it.
Goroutines are the one piece I'd nudge slightly earlier, not the memory model behind them, but the practical "don't share that map without a mutex, mind the captured loop variable" stuff. The race detector drills those in faster than any paragraph about memory ever could.
(I ended up writing a whole separate deep-dive on the escape-analysis / GC / pprof side, so if that layer is what you're after, it exists.)