6 ms·

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 enterpri

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 ;-)

jshen 15y ago
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.
- virtualeyes 15y ago
  Exactly, with caching the application server becomes far less of an issue. There's a catch, though. Twitter, is a live service, content is constantly changing, which means round-trip to app server required, and that is where dynamic languages suffer, under load. re: "I can assure you that espn.go.com could easily be served with ruby instead of java.", perhaps, but like Twitter, they chose the JVM and not the Ruby runtime. That's the "big site" de facto choice, compilation over runtime, whether it be .NET, JVM, or, perhaps in future for the enterprise, functional a la Haskell, Erlang, etc. re: the best backend being the cheapest, depends on what you mean, hardware is not everything, the application has to be developed and maintained, bandwidth accounted for, etc. But yes, I can roll with that, minimal hardware expense to get the job done. Now, if you're implying that compiled languages are more expensive than their dynamic language counterparts, not sure if that is necessarily the case. I run a couple of Dell R610 ESXi servers in colo, small setup, but complete overkill for actual load we're handling. At any rate, Scalatra (Scala Sinatra clone) running on Jetty "costs" 38MB of RAM per instance, not exactly expensive.
kalleboo 14y ago
If you haven't seen Twitter errors recently that just means you haven't been working with the Twitter API enough.

jshen 15y ago

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.

virtualeyes 15y ago
Exactly, with caching the application server becomes far less of an issue. There's a catch, though. Twitter, is a live service, content is constantly changing, which means round-trip to app server required, and that is where dynamic languages suffer, under load. re: "I can assure you that espn.go.com could easily be served with ruby instead of java.", perhaps, but like Twitter, they chose the JVM and not the Ruby runtime. That's the "big site" de facto choice, compilation over runtime, whether it be .NET, JVM, or, perhaps in future for the enterprise, functional a la Haskell, Erlang, etc. re: the best backend being the cheapest, depends on what you mean, hardware is not everything, the application has to be developed and maintained, bandwidth accounted for, etc. But yes, I can roll with that, minimal hardware expense to get the job done. Now, if you're implying that compiled languages are more expensive than their dynamic language counterparts, not sure if that is necessarily the case. I run a couple of Dell R610 ESXi servers in colo, small setup, but complete overkill for actual load we're handling. At any rate, Scalatra (Scala Sinatra clone) running on Jetty "costs" 38MB of RAM per instance, not exactly expensive.

kalleboo 14y ago

If you haven't seen Twitter errors recently that just means you haven't been working with the Twitter API enough.