Why I chose Go for my backend

As someone who not only worked in the .NET stack but was a big advocate of the C# language, looking at other languages was something I avoided. It felt a bit like cheating, as the time I spent there could have been spent learning more C#. I have heard a few times when listening to streamer @theprimagen or even @bashbunni talk about Go, but never really thought much of it. However, my first serious consideration of Go was when I was speaking to someone at Monzo and realized that their stack is Go, which surprised me. As a bank, I would have thought the .NET stack would be more suited to such an enterprise and accounts-based system. I did a few more dives into who uses it and found that Uber and Google are also all in on Go, which raised my curiosity.

In August 2024, I decided that I would try to learn the language—not for anything serious but just to satisfy the itch I had developed researching it. I purchased a course created by YouTuber @anthonygg_, who explained everything very well. It took 4 hours of solid coding and learning to go over the entire language, which was a shock, as the C# language I’ve spent months on still has stuff I haven’t fully covered and understood.

It was an enjoyable language to code in, as the syntax was simple and didn’t require much to get something started. After setting up my Neovim environment, I decided that I would redo my startup idea, which I had already partly started in C# .NET, to try Go. Using Go as the main language for my startup gave me the flexibility to quickly get off the ground and experiment. It also aligned with my vision of Jurii as a startup that plans to make big disruptions in the lawtech industry. Having a base that allowed me to build things from the ground up was important, as well as embracing the fully open-sourced nature of Go and avoiding being locked into someone else’s ecosystem.

“The only way to learn a new programming language is by writing programs in it.” – Dennis Ritchie

In January 2025, I started my first line of Go code on the platform. Late nights and weekends, on a caffeine and music-induced high, I wrote line after line of code. It felt truly liberating—no more endless decisions about where to put my files, into which project, no more deciding if using IEnumerable or List was better, or dealing with scaffolding and project architecture before I could get my first lines of code in. This might be a skill issue, but honestly, the decisions are real and it’s still something I go through every time I implement a new feature in .NET. With my Go project, I didn’t even have any endpoints; I went directly into the service layer and started implementing the services and testing them without thinking about how to structure the project. This caused me problems later (I’m still trying to solve them, lol). But the point was that you can get from zero to hero in a matter of minutes.

Another thing I enjoyed was reinventing the wheel. Sigh, I know every coder everywhere is going to say, why do something that’s already been done by someone else? But my point was not only the fact that I was trying to learn, but also that I wanted to avoid endless dependencies in my project. If there was a feature or something I liked, then I redid it in my project to give me control of the source code and avoid importing 99 other things that I didn’t need. It also allowed me to code more and learn a lot faster.

Go’s error handler has been subject to endless discussions and even pain points about the language. Coming from a C# background where everything was thrown as an exception and there were various exception handlers to catch and return something meaningful, this approach was very different.

model, err := getEntityByID(userId)
if err != nil{
    return err
}

This was all over the codebase, but it taught me several important practices that I use every time I write a function:

• The return-early pattern: Return as soon as something goes wrong or you’ve completed that function’s purpose, as we don’t really need the application to parse through other lines of code unnecessarily.
• Handling errors everywhere: This is an important part of writing resilient code, but since Go forces you to do this, it quickly becomes a habit. Making sure things are not null and won’t break when you try to access them later is vital to a functioning system.
• Results pattern: I didn’t really notice this at first, but Go functions with their error returns follow something similar to the Results pattern. This allows you to avoid exceptions and simply return the result of running that function. The handling of running the function should be dealt with by the calling code, rather than throwing an exception inside the function.

All in all, writing Go not only reignited my fire for coding but also helped improve the way I write code. Writing clean code was a good habit to pick up. I would 100% recommend learning Go and using it in your back end over Python and JavaScript, as just by simply using it you get a huge performance improvement, type safety, concurrency, and a better experience for your back-end projects. Btw, I’m not only saying this because I like Go—it’s also the fact that I have written a back-end project in Python before and tried one with JavaScript (Node), and they are not meant to be there. Just because a car can drive doesn’t mean it’s suitable to enter an F1 race and compete.

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupéry

Go forth and write some Go.