Can you define big? I've worked on some big sites that used MRI ruby for APIs and we served a ton of traffic with strict SLAs for a max of 250ms at the 99th percentile and things like that.
oh, Twitter (Scala/Java), American Airlines (Java), Facebook (on HipHop in C++), Stackoverflow (C#), ESPN (Java)
I think by big that's a code word for enterprise.
The big sites you have worked on are comparatively small if Ruby is backing the show. That's not to take away from the ton of traffic that you guys were able to serve; it's just that there are few enterprise level Ruby backed sites running these days.
Github, I believe is one, but lately I've been getting the "unicorn is angry" icon when viewing repositories, so I wonder about scalability issues. For the record, I have never, ever seen a "unicorn is angry" icon on Twitter. Maybe switching to the JVM got rid of all the magic ;-)
That's not a clear definition. If I guess what you are implying is that "big" means a top 100 site. Enterprise is not the same thing as big, at all. They may co-occur often, but they are orthogonal.
"The big sites you have worked on are comparatively small if Ruby is backing the show."
That's a big assumption. You have no idea who I am or what I've worked on. One of the sites I worked on was yellowpages.com. That's a top 1000 site, but even that doesn't tell the full story. When I was there we were serving ads for most requests to bing maps. Do you consider bing maps comparatively small?
I currently work for disney who runs espn.go.com. The person sitting next to me right now worked on espn.go.com before she transferred to my group. I can assure you that espn.go.com could easily be served with ruby instead of java.
I'm questioning a couple of specific claims made by bad_user. That all big sites use the JVM or c/c++ or .net. I think that is false, or the definition of "big" is so narrow as to be meaningless for 99.9% of programmers. I'm also questioning the claim that the best backend is the one that is the fastest. I'd argue that the best backend is the one that is fast enough and the cheapest, wouldn't you agree? As I mentioned before, I was working on an api that served requests for bing maps with a very tight SLA. We ran it on MRI ruby, and we met the SLA.
Here's something that people often forget, you can put things like varnish in front of your API. This doesn't work for everyone, but if you're API is easily cached, then you shouldn't have any problems scaling it even if you're using a language like MRI ruby which has a GIL.
Can you define big? I've worked on some big sites that used MRI ruby for APIs and we served a ton of traffic with strict SLAs for a max of 250ms at the 99th percentile and things like that.