[liamzebedee]

Yes it is nice to see continued progress! Could someone explain to me what this negative press is about? I understand that Rails and Ruby by default are not as performant as Node/Go/the JVM but it supposedly functions quite well for relatively large websites (~10K users).

[dhh]

Here are some Rails sites: Basecamp, Github, Shopify, Airbnb, Soundcloud, Indiegogo. All have millions of users.

[mattangriffel]

Here's a list of about 35 popular Rails sites I've compiled: https://onemonth.com/ruby-on-rails-example-sites

[alco]

This list says little about Rails' productivity benefits without also stating how much is hidden behind it (in terms of queues, caches, async workers, etc.) to let those services handle their job.

[shadowmint]

I think you mean 'relatively small websites (~10k)'

...but yes; thats the main complaint of any substance.

[enraged_camel]

Which is confusing. I thought some huge websites (Twitter and Hulu come to mind) use Rails?

[shadowmint]

Twitter is particularly notorious for once being an extremely heavy user of rails, then in ~2010 for abandoning ruby for the JVM and reporting the result was substantially faster.

...this is all ancient history now though. Come on, 2 seconds on google will find all the arguments and counter arguments about this stuff.

[vidarh]

Twitter is also particularly notorious for blaming Rails when it is/was blatantly obvious their architecture at the time was a total mess. Including using Rails for stuff that should have been factored out into a separate shared-nothing backend service regardless of the frontend language/framework. They could have rewritten in pretty much anything and made it faster/more reliable.

[djur]

LinkedIn also had a "Rails->Node" success story where their original architecture used a Rails app as a thick proxy to (apparently relatively slow) backend services. It should be unsurprising that Rails was a bottleneck in that case.

I have yet to read a major "moving on from Ruby" story where it was clear that the use of Ruby and/or Rails was a mistake from the beginning. An architecture that works for 1000 users/day will need to be revised for 100,000 users/day, but that doesn't mean that it would have been a good idea to use the 100k architecture for the 1k product.

[Legion]

Twitter's experience was also on pre-1.9 Ruby, ie. before YARV.

Ruby itself has made major jumps forward in performance since then. Much of Ruby's reputation for slowness was earned on an interpreter that no longer exists. It's still not the fastest dog on the track, but it is a ton better than those earlier days.

[enraged_camel]

I've spent more than 2 seconds on Google for this topic. This StackOverflow post[1] was actually very informative. See the answer by Jörg W Mittag, specifically this quote:

>>In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.

Then again, that seems to have been written in 2010. I'm sure things changed since then.

http://stackoverflow.com/questions/3514633/do-ruby-on-rails-...

[retr0h]

yellowpages.com now yp was a large rails shop, and subsiquently moved to node.

[mhartl]

Do you have a reference for this? I did a Google search for "yellow pages rails node", but it turns up your comment as the #1 result.

[retr0h]

Knowledge from having worked there.

[kibibu]

Here's why I will not touch Rails: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...

IMO it deserves bad press for favouring development speed over sensible defaults and safety. Frameworks should not be allowing SQL injection in 2014.