Go lang is a bittersweet language, powerful but it’s weird for sure. I have been working with it for quite some time now, but now I am taking it back to the basics. There are ample resources available — YouTube does it for me.
This time, I’m not “learning Go” to ship something quickly. I’m unlearning the shortcuts I picked up along the way.
When you work with a language in a production setting, you start optimizing for delivery:
“It compiles? Ship it.”,“Tests pass? Good enough.”, “Works locally? Done.”
And Go lets you get away with that.
That’s the beauty and the danger of it.
Go feels minimal. Almost too minimal.
No inheritance.No generics (well, not for the longest time).
Error handling that looks repetitive.Explicit everything.
ok,…?
Coming from Java or other OOP-heavy ecosystems, Go feels… underwhelming at first.But then you start noticing something subtle. The simplicity is intentional. The language forces you to:
Think about composition over inheritance
Be explicit about error handling
Keep abstractions to min
Prefer clarity over complexity
And that’s uncomfortable. Because most of us enjoy clever code. Go does not reward cleverness.It rewards readability.
Back to Basics (The Real Ones)
This time, I’m revisiting:
- How interfaces actually work (implicit implementation is still magical)
- Zero values and why they matter more than you think
- Goroutines beyond “just add go keyword”
- Channels — not as queues, but as synchronization primitives
- Memory allocation patterns
- Escape analysis
- How the scheduler behaves under load
- Arrays vs Slices to the root When you first learn Go, goroutines feel like threads. But they are not threads. They are lightweight user-space constructs managed by the Go runtime.And the runtime is where the real story lives.
Become a Medium member
There is still to understand:
- How the scheduler maps goroutines to OS threads
- How blocking syscalls are handled
- How GC pauses actually affect latency
- You stop writing “concurrent” code.
- You start writing “coordinated” code.
The Weird Parts
Error handling in Go is verbose.
if err != nil { return err } becomes muscle memory. At first, it feels like boilerplate. Later, you realize it makes control flow explicit.
There’s no hidden stack unwinding.No implicit exception propagation.No “surprise” execution jumps.It’s boring.But predictable.And predictability scales.
What I’m Realizing
The deeper I go (pun intended), the more I appreciate that Go is less about language features and more about engineering philosophy. It’s opinionated without being noisy.
It assumes:
You care about performance.
You care about simplicity.
You care about maintainability.
And if you don’t, it gently pushes you toward it.
Why Go Feels Weird
Because it removes the abstractions we are used to hiding behind.
There’s no inheritance hierarchy to lean on.
No annotation magic.
No heavy framework shielding you from runtime behavior.
Java, I still fear as I studied it and then used; this narrows the scope to what you know and what is being used.
You make the rules this should be done in this case, but in action you see the rules change and your basics shaken.You go back to books. And with java there is no limit.
This Time Is Different
Earlier, I was using Go. Now, I’m studying it.There’s a difference.
I have seen it in action and as I study I connect the dots. Maybe its better to just jump headfirst and then understand…
Using a language means you know how to make it work. Studying a language means you understand why it works.Neither can be traded off. But order you decide.
And that’s where the real growth begins. And maybe that’s the point.
Top comments (0)