The shiny new tool fallacy

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 the lesson I took from this story: a tool's technical merits matter less if the team cannot hire for it, maintain it, or ship with it. There are exceptions—Jane Street is one—and I'll get to those 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

The same trade-off applies beyond Go. It matters whenever a team commits to a language, framework, or tool that has a small hiring pool and ecosystem. 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 is why large companies often stick with Java, Python, JavaScript/TypeScript, or C# despite their warts. It usually isn't a lack of interest in newer tools. Those languages solve several practical problems:

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. ↩