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