$ cat choices/ruby.md
the call
I reach for Rails when the goal is to get from idea to shipped as fast as humanly possible. Its conventions are the velocity. The discipline is knowing the moment a workload outgrows it, then carving out that one piece instead of fleeing the whole stack.
Nothing gets an idea into the world faster. Rails gives you the whole house pre-wired (auth, jobs, migrations, conventions) so the team spends its energy on the actual product instead of plumbing. Early on, velocity is the only metric that matters, and Ruby buys more of it per hour than almost anything else. You ship, you learn, you correct. That loop is the entire game before product-market fit.
Ruby’s strength is also its tell: it trades runtime performance for developer speed. So when the workload turns into heavy IO, raw CPU, or real concurrency, the language starts fighting the job. Reaching for Ruby there, because it’s what you know, is the same mistake as reaching for the shiny language to pad a résumé. The skill isn’t loving Ruby or hating it. It’s knowing the exact point where it stops paying for itself and being honest about it before the pager goes off.
Ruby and Rails were the workhorse at Brandfolder, CommercialTribe, and iTriage. The fastest path from idea to shipped, over and over. The limit showed up cleanly: at Brandfolder, generating large zip files was heavy IO, and Ruby crashed under it. The answer wasn’t to abandon Ruby. The rest of the app was healthy and fast to build on. We carved out that one piece into Go and left everything else exactly where it was. Right tool for the one part that hurt, and nothing more.— see: works / Brandfolder
Pick the tool that matches the stage and the workload, not the tool that flatters you. Ruby wins on velocity, so you ride it as far as velocity is the constraint. The day a specific piece outgrows it, you cut out that piece, not the foundation. Most “we have to rewrite everything” panics are really one hot path that needs a different tool. Find that path, fix that path. See where this lands when it’s time for the other tool: choices / go.
the gaps — what it costs even when it’s right
The velocity has a ceiling. The same conventions that get you shipping fast become the thing you fight at scale. The speed that wins year one is not the speed you need year three, and you have to see that turn coming.
It hides the bottleneck until it bites. Ruby’s so easy to keep building on that the hot path stays buried until it falls over in production. The honesty is admitting where the runtime can’t follow, before the workload proves it for you.
”Just stay in Ruby” is its own trap. Loyalty to the language you’re productive in is as expensive as chasing a new one. The discipline cuts both ways: don’t flee the stack, but don’t force it past where it fits either.