You know the drill. Fast iteration cycles. Non-stop A/B testing. Inevitable pivots. Building a technology product in a startup environment requires a working setup that differs significantly from more prominent or more established companies. In no small part, the choice of a tech stack can play a crucial role in whether the startup can find its product-market-fit quickly enough.
In a recent episode of the popular Go Time podcast, host Jon Calhoun spoke to four startup founders who bet the future of their companies on the language and its stack.
I can summarise my takeaways from this discussion as follows: even if Go might feel more verbose and stricter than some of its contenders, it pays off multiple times over (in the long run) in terms of clarity and stability.
For us it was an easy way to get started, not worry about performance for a very long time, and just be able to focus on that MVP and making sure we just offer the functionality we wanted to build, without having to worry about “Will it run everywhere? Will it scale?” and all those things.
All of the participants in the podcast agreed about the following:
- Go applications compile extremely fast.
- They can be painlessly deployed to any major operating system and cloud platform
- Last but not least, they keep the same level of small resource consumption and fast performance, even as products grow.
[...] the binary coming out of Golang - I can run it now and I will be probably able to run it with no modification five years from now, which is from my perspective great. And you know, building a technology for a startup knowing - just like Ramiro said - that performance issues won’t exist for a very long time… And the scalability of the technology made Go a natural choice.
One of the aspects of Go that strikes many newcomers to the language is the lack of a single "winner takes it all" kind of solution for most problems. The same applies to project structure - one will not find a single place in the documentation providing explicit guidance on how a project should be structured. The only piece of advice is the usual "keep it simple." While this may sound obvious and even off-putting to some, it carries a certain level of reassurance. Almost like permission to focus on the problems that software should solve and leave structure to grow naturally.
Joining the Go club after almost a decade of writing enterprise-grade Java apps, I was initially confused by what I thought back then looked like utter chaos. Every Go project I looked at had a different structure, and I was desperate to get back to the patterns I had used to fall into over and over again. Only when I started building my first real production apps did I fully grasp the meaning of "keep it simple." It looks like others have had a similar experience:
What I like about Go is that it actually suits perfectly the startup world. The functionality you need, you always need it yesterday. You can put it in, and making it nice comes later… And I really appreciate it, because I really don’t like the frameworks where I need to study hundreds of pages of the framework documentation just to put something in, because I have to follow a certain structure.
If you want to read more about project structure in Go, host Jon Calhoun recently wrote a great article on this topic:
If you don't care reading the entire article, keep this brilliant quote in your mind:
[...] using a structure that is far more complex than needed can actually hurt a project more than help it.
Do you have a startup story with Go worth being told? Don't hesitate to get in touch with me. I'd love to hear it and share it with our audience.
Pssst ... wanna see a cool new app built entirely with Go? Yes, entirely with Go (a topic for an upcoming post)! Check out Murmel, and feel free to try the free beta. We would love to hear your feedback.