Over the years, I’ve been fortunate to learn and work with a wide range of technologies. Including C#, C++, C, Java, PHP, and JavaScript. Recently, curiosity led me to try Go. I didn’t pick it up casually or just to follow hype. For me, a new language has to earn its place in my toolset. It has to make me more effective, more efficient, and better equipped to solve problems.

So the question I wanted answered was simple: is Go just hype, or is it a hidden gem worth adding to my stack?

When I’m working on projects that require consistency and a clean, well-defined structure especially large, scalable services with strict type enforcement, I naturally reach for

. Its ecosystem is mature, structured, and full of frameworks that make building enterprise-grade systems predictable and maintainable.

From my experience so far, Go has a bit of that discipline but it approaches structure very differently. It sacrifices heavy convention and rigid architecture in favor of flexibility. You’re free to organize things the way you prefer, which feels closer to setting up a project in

with .

The syntax can take a moment to get used to. It’s not difficult, but it’s different. And you’ll find yourself wiring up many things manually. You typically get a server object that provides routing capabilities, middleware handling, and the basics you’d expect but beyond that, a lot is left up to you.

For example, you don’t automatically get request-layer validation out of the box. In Go, you implement that yourself. It’s

, which gives you both compile-time guarantees and some runtime safety but don’t expect things like a enforcing model structure the way some higher-level frameworks might.

In many ways, Go gives you power and responsibility in equal measure. I’m not writing this to critique or rank Go against other languages. That would be unwise. Every technology solves problems in its own way, and those design decisions often reflect the kind of problems it was built to handle. I’m mature enough to accept that.

If I don’t like a technology, I simply don’t use it. Or I choose what fits the problem better. Right now, I’m building a simple CRUD application in Go nothing fancy. Just enough to see how it handles structure, routing, validation, and database interactions.

Figure 1 - A Read Operation

As I mentioned earlier, I’m not in a position to recommend Go or not recommend it. But I can confidently say this: I’d love to use it when the need truly arises. And what does that need look like? It might be one of my services where latency truly matters and performance isn’t optional. Go feels like it belongs in environments where efficiency and simplicity at scale are priorities.

Would I use it as my main language for setting up a typical common.api today? Not yet. I already have a tool in my stack that handles that exceptionally well. But Go has definitely earned my attention.

For now, I won’t be replacing my primary stack with Go. But I won’t ignore it either. It has earned a spot in my toolbox, and when the right problem presents itself, I won’t hesitate to reach for it.