Why did Stripe choose to use Ruby for its backend language?

Ruby is a pretty good general-purpose language. It's reasonably powerful, it has a large community, there are lots of actively-maintained libraries, and it's sufficiently widely deployed that you're unlikely to hit big, unexpected problems. When we were starting out, John and I also already happened to know it pretty well. We chose it because it was a sane default.

Picking Python would probably have worked out equivalently well. Between the Ruby and Python, each is a little better in some areas, but the differences between them are fairly slight.

There are a lot of less-commonly used languages that could potentially have been good choices: Clojure, Scala, Haskell, Go, Smalltalk, and Julia jump to mind. Though picking one of them for any major project entails some risk (maybe the language declines significantly in its already-limited popularity; maybe you start having to waste effort investing in the language itself (as Jane Street has had to with OCaml); maybe you have to write a lot of libraries; maybe you're slowed down because people have to spend time coming up to speed with the language; maybe you hit major bugs), I think startups tend to underestimate the potential benefits of picking atypical technology stacks: learning new things is a powerful motivator for engineers—disproportionately so among those you're most likely to want to hire—and having an interesting and thoughtful tech stack can help a lot in recruiting. (Cases in point: Prismatic (Clojure), Foursquare (Scala).)

We used Smalltalk for almost everything at our previous company (Auctomatic), I'd previously written a lot of Lisp, and some of Stripe's early engineers built startups in Objective-J, and so we weren't strangers to this phenomenon.

From the start, we've had a somewhat modular codebase, and the Stripe product is composed of many independent services. Over time, I expect them to diverge somewhat in their implementation, as the priorities and requirements for each become clearer. (Already, the bulk of our web interface is written in CoffeeScript, not Ruby.)

Building Stripe this way makes the initial choice of language less important. By hiring strong generalist engineers, and maintaining the flexibility to implement various components in different ways, we've kept the option of using other languages in the future. To some extent, using Ruby was a conservative choice, made with the goal of maximizing the chance that we'd build a sufficiently stable foundation that we could then go and experiment—with a greater margin for error—with other technologies and frameworks in the future.

Seen this way, I think the choice has worked out pretty well so far.