Throughout my career, I've worked in a variety of environments, from fast-paced startups to established software factories. Whether dealing with in-house code or outsourced teams (let's move away from the term "talent"), one constant remains: development processes are often optimized for small or greenfield projects, which serve as the foundation for a company's codebase. While it's relatively easy to swap out developers on a project, this does not mean that technical debt—especially from choosing the wrong language or tool for the job—will be less costly than investing in the right technology from the outset.

As a case study, I'll discuss a project I've been developing over the past year, which I intend to build into a company. The backend was initially written entirely in Golang, chosen for its efficiency and speed in cloud environments. Go compiles quickly and is exceptionally performant, making it ideal for scalable cloud applications. However, as I began integrating Gremlin (Apache TinkerPop) for graph database operations, I encountered significant challenges: the Gremlin API is written in Groovy, a JVM language, and is best supported by other JVM languages like Java and Scala.

Adhering strictly to the Gremlin API using Go proved difficult. I found myself relying on Java documentation to understand which parameters were accepted, which quickly became unsustainable. Eventually, I decided to refactor and migrate this repository layer to a JVM language. Not being particularly fond of Java, I explored Scala, which offers strong integration with other Apache projects like Kafka—opening up future possibilities for seamless tool integration. Although new to Scala, a few days of studying documentation, consuming "Rock the JVM" content, and leveraging Copilot helped me grasp the basics. My prior experience with the Gremlin API, combined with Scala's clear method overloads, allowed me to rapidly improve both my integration and my understanding of the framework.

I'll skip the technical details of integrating the Go-based domain codebase, generating services in Go, and consuming the repository layer in Scala—suffice it to say that gRPC, wrappers, and facades abstract the flows and unify both languages within a single codebase. The key takeaway is this: while Go is excellent for cloud-native development, it cannot do everything. Choosing the right tool for each part of your system not only streamlines development but also future-proofs your codebase. Too often, teams defer these decisions, thinking, "We'll migrate and improve the codebase later," but in reality, such migrations rarely happen. Selecting the right tools from the beginning ensures that any future refactoring is an enhancement, not a costly migration between languages or frameworks.