Home

How Go Lowers Tech Debt

by Tristan Donnally

Web Development Agnostic

Before I begin I want to provide some small context beyond the title. I am specifically writing about web application development. I believe Go is a language that can be used in many situations but this is the use case I am focusing on because that is where my experience lies.

There are many different technologies that can be used to build similar applications. You can build your server using PHP, JavaScript, Python, Go, Rust, Java, or any of their associated supersets and frameworks. For the frontend you can serve HTML, HTMX, React, Vue, or Svelte components(or any other Javscript framework for that matter). All of these can produce a valid result. In this regard, I believe I am unopinionated on what should be used for a given project. Almost always you can approach a project with any tool and get a working result. At the end of the day we are all just digital plumbers connecting pipes to get data from Point A to Point B with varying degrees of complexity.

The Issue

But when discussing programming on the internet you will get a wide range of strong opinions. Every day I have seen some version of the following takes:

"X language is bad because of Y," says Developer 1. Feeling attacked because they love X, Developer 2 exclaims "No! X language isn't the problem you are the problem! You did Y when you should have done Z!" "Yes," a third developer chimes in, "also they added a new feature, Q, in version 1.2.3 so you could have also done Q!" (I ran out of variables and had to go backwards)

Whether developer 1 is misinformed or unexperienced or if developer 2 and 3 are replying emotionally and irrationaly is not the point. They may all be right. They may all be wrong. The point I am trying to make is that many times developers can have widely different views on a problem and how to solve it even within the same language.

Also depending on the time you reach this debate the language could have completely transformed so none of the approaches in the original thread are valid or efficient and a new method or technology has arised to make the old advice obsolete.

Both of these issues can lead to an increase in tech debt within a codebase. Maybe a developer did not fully understand a languages features or libraries before jumping into a project(I am extremely guilty of this) or maybe the landscape has shifted to where the old way of doing things is no longer used and therefore future features are developed in an extremely different way. Now developers in the present are stuck maintaining the old way or the inefficient way while also trying to keep up with new standards. These types of problems are unavoidable but they are also expensive and complex. Wouldn't we want to reduce this type of tech debt at all costs?

This is where Go comes in.

The Magic of Go

I first started using Go on a whim without really knowing anything about it but within the first hours of picking it up its power became immedietely apparent. There are three key attributes that make it extremely useful in lowering tech debt and they are as follows:

1. The syntax is simple

The existence of only 25 keywords, one loop, no inheritance or operator overloading, explicit errors instead of exceptions, and interfaces that are satisfied implicitly are all examples of this design philosophy. There are also no classes or inheritance. Data is modeled with structs and behavior is added with methods. Are the type systems in other languages richer? Absolutely. But I prefer Go’s due to the readability.

This simplicity is also a point of contention for detractors of Go, who say the lack of features can lead to extra verbosity where developers may have to write additional lines of code to achieve the same result as in another language. This is true. But those extra lines remove vagueness, and most code can be read top to bottom and understood easily.

This simplicity translates to less tech debt because the inclusion of fewer features means there are fewer patterns to choose from. I could also mention auto formatting, but this feature is not unique to Go and is present in many other languages.

2. The solutions you create today will be similar to the ones created years from now

Go is extremely stable and backwards compatible with new features being extremely conservatively released. Again, critics of the language find this unappealing(why isn't there enums!?!) but this can be appealing to organizations who favor consistency in their codebases.

To expand upon the point we made earlier Go's simplicity will not only cause projects to be similar but will cause most packages within a codebase to follow a similar flow which adds to the overall readability.

This consistency and simplicity means fewer rewrites. Docs from years ago are still useful, packages don’t break between releases, and new developers can hop into any Go codebase with ease. The cost of maintenance stays low because the language and its tooling stays very consistent.

3. It is fast

This isn’t unique to Go but it separates it from most interpreted languages. Throughput is very high due to Go’s concurrency model. Goroutines cost far less than OS threads, and the scheduler efficiently multiplexes them so you can handle many connections with low memory. Also the garbage collector is extremely efficient (and in some rare cases can make programs run faster than non-GC languages).

Why is this important? If you were to begin your project in Go you can be assured that you will not need a rewrite when it is time to scale. Companies like Uber, Dropbox, Paypal use it and so do tools like Docker and Kubernetes so more often than not it will be a viable option for your project.

Conclusion

Since beginning my adoption of Go it is always been surprising to me how divisive it is. It seems you either love it or hate it. Though going back to our introduction I am language agnostic and I believe many languages are viable solutions for web application development. I think the issues in perception are caused by how we use the tools. If you try to use a saw like a hammer or vice versa you are bound to be frustrated and you to will end up sounding like developer 1 I mentioned earlier. Until you can adopt the mindset needed for the tool you are using(saws cut wood; hammers drive nails; both are used to build a house) you will be frustrated.

With that said Go can create a stable, long lasting codebase which is an extremely great advantage in an industry where technology moves so fast and development can create such large costs. I can talk about more of the benefits of the language but I will try to keep this article within the scope of how this tool impacts tech debt. It is one of the reasons why when I start a new project, Go is always a contender to be the tool of choice.

Stay in the Loop

Sign up for updates on our latest posts and major releases plus occasional tips, case studies, and behind-the-scenes notes. No spam, ever. Unsubscribe anytime.

Ready to Forge Your Next Project?

Tell us a little about your project and we’ll get back to you within 1 business day.

What are you interested in?