Where Is the Spring Framework for Go?

Those who have been following my blog know about my appreciation of Go. It’s a fantastic tool to have in every developer’s toolbelt. I have used it as an effective Bash replacement for small app ideas and for building entire online platforms. At the same time, I owe most of where I am today to the Java developer ecosystem; it provided me with my first job while I was still in college and has taught me much of what I know and appreciate about software development to this day.

Having left the Java world for a couple of years, I discovered Quarkus in 2021 and immediately felt at home. Quarkus shares the same philosophy about building large-scale applications as Spring, but it has been influenced by Go and Rust as well, as it favors building leaner and faster applications with only a fraction of the runtime shenanigans that go in a Spring app.

Spring and Quarkus are both what I consider full-stack frameworks. They may be big and bulky, but you learn them once and can use them for multiple projects onwards - both large and small. At the same time, the situation with Go is more of a pick-and-choose style. While the standard library covers a lot of needs, a sizeable real-world application needs a variety of 3rd-party packages to bridge the gaps. Some are outstanding; others look like something someone did on the weekend without any intention to keep at it. The process was fun the first time around, but after the third project I did, I started wondering if I was using Go for the wrong use case or if the community could really benefit from a well-designed and maintained, higher-level tool.

By now, I am pretty convinced that @QuarkusIO is the best thing to have happened to the Java ecosystem for the last few years. I only have one wish: given @RedHat's contribution to #golang, how outstretched it is to see a Quarkus for Go one day? I can help contribute to it🙋‍♂️

— Preslav Rachev (@preslavrachev) March 21, 2023

By this point, many people with Go experience reading this post will be like, “we don’t do those things here." Some would educate me about Go’s philosophy, the explicit nature of its code, the emphasis on simplicity, and on and on. I get that, which is part of why I enjoy the language too. But at the end of the day, I would love to spend my time solving business problems and not reinvent the wheel. While I have collected a set of tools and libraries I pull into every new project, there are probably a million other such combinations out there. Here is another good one.

I think Go’s different philosophy is only a part of the story. The smaller part. The more significant factor is business adoption. And, as we know, business adoption is driven by money. Think of why and how you learned about Go in the first place. A language made by a team at Google, which has exploded in popularity over the past decade thanks to its ties to cloud technology, and early adopters like Docker and Kubernetes. But it was a lot of luck and uncertainty at the beginning. Does anyone ever talk about how Kubernetes was supposed to be built in Java? Or that Docker was originally prototyped in Python? Not a particularly memorable part of both tools’ histories, I am sure.

Anyway, the point I am trying to make is that it takes courage and a leap of faith to thread in new waters. At the time, it must have felt like going against the status quo - but someone took the bait and did it. And this is where we are today.

I think coming up with a solid full-stack framework for Go is the same. It will certainly be met with criticism by some, but others will gladly welcome a thing they have been afraid to ask for so long. However, it must be done by a company. I see no other way. Hobby projects on GitHub are cool, but they are just that. A business will bring the focus, resources, and, most importantly, financial backing to ensure the project remains sustainable. The company will also be the first in line to profit from the framework’s adoption - having a first-mover advantage in an area that could bridge the gap between classical monolithic software development with the entire Cloud know-how that Go has gathered over the years can quickly become the next thing everyone is talking about.

See, not everyone needs or wants to go all lambdas and fireworks from day one. Most people still need a consolidated solution that they can reason about, build, and deploy without fuss, but when the need arises, they split into a gazillion parts at the push of a button. The term du jour is “Modular Monolith,” Believe it or not, even Google is thinking about it. The company recently released Service Weaver - a framework for building distributed applications by packaging them as monoliths or microservices clusters - all by changing a single deployment configuration. If this seems awfully lot like CORBA or Enterprise Java Beans (EJB) from a couple of decades ago, it’s because it kind of is - with the difference that our understanding and expectations about the Internet from a couple of decades ago were totally different. In many respects, those early precursors were destined to fail market-wise because the underlying infrastructure wasn’t there.

I don’t see a reason for people to be afraid that the Go community will get infested with “architects “talking about “modular architecture,” “dependency injection,” “object-relational-mapping,” “design patterns, “or everything else people seem to have burned by in previous jobs. We have learned a lot over the past few decades to know how to build robust software by setting a strict policy around keeping things simple at the code level. A proper framework could rally the community around a solution allowing for modular development while offering the hard lines of simplicity and performance expected from Go users.

So, who is building it?