I read an interesting medium article by Yash Batra - where he detailed his startup's struggles after choosing Go for their primary development language.

I wanted to talk about how this story highlights a critical lesson for engineering teams of all shapes and sizes: the tool of choice is often less about the merits of the tool itself and more about what drives a team's ability to deliver quickly and effectively. There's also notable exceptions - like Jane Street - we'll get to that later.

Yashbatra's team ultimately found that moving to Go "slowed us down, sabotaged our productivity, and nearly derailed our product vision" leading them to rewrite their data pipeline in Python and eventually migrate their backend to Kotlin + Spring Boot based service which, according to them, produced more features in two months than in the previous six with our gopher king.

Many such cases

This isn't just a Go-specific anecdote; it's a cautionary tale that should resonate during long-term team decision making - especially for languages, frameworks, or really any tool that isn't yet firmly in the mainstream. Like look:

Be it (1) Go's concurrency and performance:

1package main
2
3import (
4    "fmt"
5    "sync"
6)
7
8func main() {
9	var wg sync.WaitGroup
10	for i := 1; i <= 3; i++ {
11		wg.Add(1)
12		go func(n int) {
13			defer wg.Done()
14			fmt.Println(n)
15		}(i)
16	}
17	wg.Wait()
18}

or (2) Rust's memory safety:

1fn main() {
2    let s = String::from("Hello, world!");
3    let r = &s; // immutable borrow
4    println!("{}", r);
5    // s.push_str(" This will not compile!");
6    // reason - because `r` is still in scope and borrowing `s`.
7}

or (3) Haskell's functional purity:

1module Main where
2import Data.List (sort)
3main :: IO ()
4main = do
5    let numbers = [5, 3, 8, 1, 2]
6    let sortedNumbers = sort numbers
7    print sortedNumbers

it's all very easy to gravitate towards. However, when time-to-market and iterating on product-market fit are critical - realistically, the advantages of (specific tool) may not be as impactful as they seem.

Why?

This brings me to a broader observation about why many large, established companies often seem conservative in their tech stack choices, frequently sticking with languages like Java, Python, JavaScript/TypeScript, or C# despite their known complexities or "warts." As (hopefully) expected. It's never been about a lack of desire for innovation. It's moreso a pragmatic assessment of comprehensive trade-offs. Those "boring" but popular languages offer significant advantages that are hard to overlook:

In Yash's case, they need move fast and ship features quickly - they're a startup. Using a language that has a big community and lots of libraries of course means focusing on building your product instead of reinventing the wheel. You can find solutions to problems and hire people who already know the language...quite easily.

The other side

Big companies know this well. Using a less common language means extra work: training people, building your own tools, and worrying about long-term support. Most of the time, it's just easier and safer to use a language with a big community and lots of support, even if it's not the newest or most exciting to enthusiasts.

Okay let's be real. Certain tools ARE indeed the best choice for the job. Especially for certain infrastructure projects or when your team already knows everything quite well. But for most startups, especially when you need to move fast and ship features, the "boring" popular languages win out.

As Yashbatra puts it, customers don't care what language you use—they care that you deliver quickly, fix bugs, and scale when needed.

---

Hey y'all, if you want to see Yashbatra's medium article, you can read the post here.

Footnotes

1. Refers to the extra costs and challenges that come with being an early adopter of a new technology or approach. These can include needing to build custom solutions from scratch or struggling with a small community and unclear conventions. ↩