building your golang toolkit

After nearly 10 years of working with Go, including over 6 of those years as a full-time Go developer, I’ve come to rely on a set of tools and libraries that have significantly boosted my productivity. In this guide, I’ll share the tools and libraries I use and discuss the importance of curating your own toolkit.

Other developers have shared insights on building services and the libraries they depend on, which I highly recommend exploring to aid in assembling your toolkit. Noteworthy examples include Mat Ryer’s “How I write services in Go” and his follow up, “How I write Go HTTP services after 13 years” where he shares the libraries he utilises.

The primary goal of building your toolkit is to streamline your development process, enabling you to focus more on creating rather than configuring. This guide aims not only to highlight the importance of a personalised toolkit but also to serve as a foundation for developers looking to enhance their efficiency. By curating a set of tools and libraries tailored to your needs, you can significantly reduce cognitive load and boost productivity.

The Philosophy Behind a Personal Toolkit #

Personal toolkits extend beyond Go and are pivotal in software development, offering tailored sets of tools and libraries. Go’s ethos of simplicity and efficiency underscores the value of such a personalised approach, especially when large organisations similarly cultivate their own frameworks to boost productivity.

Cognitive bandwidth is finite. Decisions, from selecting libraries to choosing debugging tools, consume mental resources, leading to potential fatigue. A curated toolkit can mitigate this by reducing decision-making and providing reliable, familiar tools, thereby conserving energy for creativity and complex problem-solving.

The process of curating a toolkit enhances efficiency by minimising the time dedicated to tool-related decisions and familiarising oneself with chosen tools, which expedites development and enables tackling complex problems more confidently.

Deep engagement with a limited set of tools promotes mastery and the discovery of advanced features, often overlooked when frequently switching between tools. Furthermore, standardising toolkits within teams simplifies collaboration, easing code sharing and maintaining coding standards.

Ultimately, the philosophy behind a personal toolkit aims to enhance efficiency and reduce cognitive load without stifling creativity. It’s about building a foundation for development that prioritises solving problems and crafting solutions effectively.

Core Components of My Golang Toolkit #

For my toolkit, I’ve assembled a set of tools and libraries that have proven invaluable in my development process. While these components are essential for me, they may not be for you. It’s crucial to tailor your toolkit to your unique needs.

HTTP #

I typically rely on the net/http package for building services, given its robust foundation for creating HTTP servers and clients. However, its limitations prior to Go 1.21 led me to often use the github.com/go-chi/chi/v5 router for added functionality. This preference may evolve with the enhancements in the net/http package introduced in Go 1.22.

Concurrency #

Go’s concurrency model is a standout feature. For basic concurrency patterns, the sync package suffices. Yet, for more complex scenarios, I find the github.com/sourcegraph/conc package invaluable for its user-friendly API and handling of intricate cases.

Database #

Favouring Postgres, I predominantly use the github.com/jackc/pgx/v5 package for database interactions and connection pooling. This, combined with github.com/golang-migrate/migrate/v4 for database migrations and github.com/georgysavva/scany/v2 for scanning rows into structs, significantly enhances productivity and efficiency with Postgres.

Logging #

Although I’ve previously used github.com/rs/zerolog and github.com/sirupsen/logrus, I’ve recently transitioned to the standard library’s log/slog package for its simplicity and one less external dependency.

Testing #

The standard library’s testing package meets most of my testing needs. However, for more intuitive assertions, I use github.com/go-quicktest/qt.

For integration tests, particularly with systems like Postgres, Google Cloud Spanner, Kafka, etc., I rely on github.com/ory/dockertest/v3 to create custom test environments.

Tooling #

So far I’ve covered libraries, but tooling is also an important part of my toolkit. I use github.com/golangci/golangci-lint for linting, github.com/golang/tools/tree/master/gopls for my language server, air for hot reloading, github.com/a-h/templ for templating and more. These tools are chosen based on project requirements and personal preference.

Future Additions #

Each component in my toolkit is chosen for its fit with my needs and project requirements, reflecting the dynamic nature of software development. As Go evolves, so too does my selection of tools and libraries, ensuring I’m equipped for the challenges of current and future projects.

Adaptability is key; my toolkit flexibly incorporates tools like Kafka, gRPC, or Redis as needed, always supported by the latest and most efficient libraries. Currently, I’m evaluating ConnectRPC for its potential in upcoming projects, illustrating my commitment to leveraging emerging technologies to maintain a cutting-edge development environment.

Building Your Toolkit #

Building a Golang toolkit is akin to embarking on a unique adventure, one that is deeply influenced by individual development style, project requirements, and team dynamics. This journey doesn’t follow a linear path; instead, it encourages you to explore, experiment, and curate a set of tools and libraries that align with your specific needs.

Begin by reviewing past projects. What challenges did you face, and which libraries or tools helped you overcome them? Identifying patterns in your past choices can provide valuable insights into your preferences and requirements. Perhaps you’ve consistently leaned towards certain routers for web services or found specific ORMs (Object Relational Mapping) or database packages that fit your workflow perfectly. Recognising these tendencies is the first step towards building a toolkit that feels like a natural extension of your development process.

Consider the scope of your current and upcoming projects. Are you focusing on web applications, microservices, or CLI tools? Each domain might benefit from different sets of libraries. For example, web services might thrive with routers like chi or frameworks like Gin, while CLI development could benefit from packages like cobra.

Personal preferences play a significant role in shaping your toolkit. Do you prioritize minimalism and the Unix philosophy of “doing one thing well,” or do you prefer the comprehensive features offered by more extensive frameworks? Your toolkit should reflect this preference, balancing simplicity with functionality as you see fit.

Team dynamics cannot be overlooked if you’re working in a collaborative environment. A shared toolkit, built on familiar libraries and tools, can significantly enhance team productivity and project coherence. Engage in discussions to understand your team’s preferences and experiences, aiming for a common ground that supports efficient collaboration. For example it might be beneficial to develop your own internal libraries or tools that are more tailored to your team’s specific needs, workflows and environments than existing open source libraries.

Experimentation is crucial. With a preliminary list of tools and libraries in hand, test them in small-scale projects or components of larger applications. This hands-on approach allows you to evaluate their fit for your needs, ease of use, and performance implications.

In essence, building your Golang toolkit is a dynamic process of discovery, evaluation, and refinement. By drawing on your experiences, staying open to new ideas, and fostering collaboration, you can curate a personalised toolkit that not only enhances your productivity but also enriches your development journey.

Staying Updated and Flexible #

It is important that you stay informed about new developments within the Go ecosystem and be ready to reassess and adjust your toolkit. The tech landscape evolves, and so will your preferences and project requirements. This flexibility ensures that your development environment remains efficient, enjoyable, and aligned with your goals.

The last thing you want to do is develop a toolkit that you never update or change. This will lead to stagnation and inefficiencies. Instead, be proactive in your approach to your toolkit, always looking for new tools and libraries that could streamline your workflow or help you overcome new challenges.

Conclusion #

Curating a personalised Golang toolkit is a continuous journey that enhances your efficiency and job satisfaction. This guide has introduced the philosophy behind a custom toolkit, essential components, and a strategy for building one that suits your unique needs. The focus has been on tools and libraries, underscoring their importance in your development workflow.

However, project structuring, another critical aspect of your toolkit, has not been covered here. Proper structuring is key to scalability and maintainability but will be the subject of future articles. Keep an eye out as we dive deeper into optimizing your Go projects’ architecture.

Remember, the right toolkit evolves with you, accommodating changes in technology and project demands. Stay adaptable, engage with the Go community, and let your toolkit reflect your development ethos. Here’s to the journey of building a toolkit that not only meets your needs but also makes coding a pleasure.