Hello everyone!
I’m a .NET developer who’s recently decided to start learning Go. Why? Honestly, it just seems cool, being so simple and still powerful. After many hours of working with .NET, I’ve also started to feel a bit burned out. I still love .NET, but it can take a toll after living deep in layers of abstractions, dependency injection, and framework-heavy setups for so long.
With .NET, everything feels natural to me. My brain is basically wired around Clean Architecture and Domain-Driven Design, and every new feature or service idea automatically forms in those terms. I’m also very used to abstraction-based thinking. For example, I’ve worked with MediatR and even tried building my own version once, which was a humbling experience. And of course, there’s MassTransi…
Hello everyone!
I’m a .NET developer who’s recently decided to start learning Go. Why? Honestly, it just seems cool, being so simple and still powerful. After many hours of working with .NET, I’ve also started to feel a bit burned out. I still love .NET, but it can take a toll after living deep in layers of abstractions, dependency injection, and framework-heavy setups for so long.
With .NET, everything feels natural to me. My brain is basically wired around Clean Architecture and Domain-Driven Design, and every new feature or service idea automatically forms in those terms. I’m also very used to abstraction-based thinking. For example, I’ve worked with MediatR and even tried building my own version once, which was a humbling experience. And of course, there’s MassTransit, which makes event-driven microservice communication incredibly fun and powerful.
That’s why I’m curious: how do Go developers typically approach this kind of stuff?
I’ve heard that Go has a completely different philosophy. It encourages simplicity, readability, and explicitness instead of deep abstractions and heavy frameworks. Many say that Go developers prefer writing code that’s “boring but clear,” rather than clever or over-engineered.
So my questions are:
1) Should I rewire my brain for Go?
Should I let go of some of the DDD and Clean Architecture habits and learn to embrace Go’s simpler and flatter style? Or is there still room for applying those principles, just in a more lightweight and Go-idiomatic way?
2) Is the event-driven pattern common in Go?
In .NET, event-driven architecture feels almost natural thanks to libraries like MediatR, MassTransit, and native async capabilities. How do Go developers typically handle domain events, background processing, or asynchronous workflows between services? Do people build internal event buses, or is it more common to just use external systems like Kafka, NATS, or RabbitMQ directly?
3) How is microservice communication usually done in Go?
Is gRPC the standard? Do developers prefer message brokers for asynchronous communication, or do they just stick to REST and keep it simple? I’d love to know what’s considered idiomatic in the Go ecosystem.
In short, I’m trying to figure out how much I need to adjust my mindset. Should I unlearn the abstractions I’ve grown used to, or can I translate them into Go in a simpler and more explicit way?
I’d love to hear how experienced Go developers approach architecture, service communication, and event-driven patterns without turning Go into “.NET but worse.”