Twitter’s issue was massive peaks of traffic combined with the way they handled persistence.

Persistence means keeping information for later, safely. In this case, databases and caches.

In small web-apps, (which Twitter originally was), the simple way of persisting data is to just write it to the database when it gets created or updated. This doesn’t work when you start having huge amounts of requests that create or update. Twitter started having issues because every time someone posts a tweet, that tweet needs to go into a bunch of other people’s feeds (people who follow the user who tweeted). If you do this within the request-response lifecycle… you’re going to be slow.

The solution is to make those “write” operations asynchronous. This means we take them out of the request response lifecycle.

How?

Usually using a different kind of persistence layer, that isn’t a database (with tables containing data or documents cobtaining data) but a *queue*. With a queue, you just add a message to it instead of having to wait for the database to update. Adding a message to a queue doesnt take longer if you have more messages in the queue, which isn’t true of writing to a database.

On the other side of the queue you have something called a worker service that reads off the queue and does something with that data. In this case, it probably writes to the database, updating some feeds etc. Again instead of writing, it could read whose feeds need to be updated and push some messages to another queue that will handle that operation.

That’s just taken the database bottleneck out of the application.

At Twitter, this wasn’t enough… mainly because they initially wrote their own queue… which, unless you’re very good at solving this specific kind of problem is just not good enough.

This queue was initally written in Ruby, then to eek out more performance, in Java. The issue turned out not to be the underlying language but the architecture of said queue. Eventually Twitter moved to Kafka which was a better fit for their needs.

That’s why Twitter struggled, not really because of Ruby but rather the architecture decisions made which happens when you grow as fast as Twitter did, they were under massive loads for short periods of time (eg. SuperBowl, world championships).

Seriously? It was in 2009. It literally is irrelevant for today as everything changed.

And for the record. After so many years I will say that this headline of Twitter moving away from Rails was stupid, written by an imbecile.

Neither Rails nor ANY other Web framework in any other language would have helped.

Twitter figured out it was a message broadcast system. Better served only by distributed systems such as Erlang/OTP (which was harder to learn back then, but the architecture was proven by stuff such as ejabberd). They chose Scala, whose actor framework is a semi OTP clone attempt (I say "attempt" because JVM limitations disallow them to match Erlang, anyway I digress).

So this is the correct headline: Twitter backend core (as the front end system remained in Rails), pivoted from traditional Web frameworks to distributed message broadcasting system, particularly written in Scala.

Not as sexy as making it seem like Rails is bad somehow.

Finally, 99.9999% if business will never, ever, achieve the size of Twitter. So knock it off, their core choices can't be references to most business. Don't compare yourself with Twitter.

I hope I don't see this idiotic headline being repeated without understanding anymore. I curse the original author for this viral spreading of stupidity.

There are two blog posts by the Twitter engineering team that directly address this question:

• Twitter Search is Now 3x Faster
• The Engineering Behind Twitter’s New Search Experience
  

And there is a good overview on InfoQ:

• Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers

RoR is not hard to scale. However, Scala tends to be more efficient than Ruby which translates into smaller hardware costs and lower latencies. For these reasons Twitter is moving most if not all of its backend services into Scala and/or Java. However, they still use RoR for their front end as it is easier to iterate with RoR and front end servers are typically easier to scale than backend services.

Twitter switched... partially, to Scala. They've used RoR for their front-end parts, and started moving a lot of their back end API to Scala. How they did that? They weren't quite at 200 Million users. This happened back in 2009 when things weren't nearly as developed as they are now. There were around 8-10 million users at the time. It wasn't nearly as fully fleshed out as as it is today. Doing it today would have been a herculean effort.

So, it wasn't like they were rewriting their entire codebase, they moved their SOA's to something that was a little more aggressive with concurrency models on the JVM for their message queues. And JRuby wasn't nearly as developed in 2009 as it is today.

I'd assume there was a lot of rewriting of API's through TDD. They've spoken at length about the amount of TDD that they've done, and when you're just rewriting test cases from one language to another, it's actually considerably easier to accomplish when you have known test cases to green.

Difficulty level? Probably hard from an architectural standpoint, but from a coding standpoint? It probably wasn't very hard... Scala's typing was something that was very important to Twitter though, that they admitted, even the best TDD wasn't able to solve for them. They were excited about Scala's strengths, moreso than Ruby's weaknesses, and that positive momentum probably made it an easier transition.

I don’t know if it is fair to say it’s no longer popular, it just doesn’t have the hype that it did when it was released when it came out. But that’s true of just about any framework. We like new, shiny things, so a brand new release (if it’s any good) gets loads of attention and then slowly starts to stabilize.

But Rails is still very much around and in demand.

I recently published an article, Rails Isn’t Dead, Not Even Close: 6 Advantages Keeping It Alive, that has a small section on Rails on the professional market.

Here is the TL;DR version:

While there are no specific metrics to quantify how many—at least none that I can find—you can do a standard job search on any platform to see how prevalent Rails’ jobs are.

In his article, “Demand for Ruby on Rails Is Still Huge,” Yoel Blum makes it as simple as running a job search in Linkedin. This is what he found:

San Francisco Bay Area:

• Rails 1066
• Django 636
• Spring MVC 304
• ASP.NET | Open-source web framework for .NET 298

The list goes on, but you get the idea. Feel free to do a similar study in your own area and you're bound to get a similar result.

If you’re interested, there’s also this video presentation that discusses the advantages in more detail.

Hope that helps!

Two reasons:
1) The problem is complex, and 2) No language stops you from writing problem free code.

1) Twitter receives a few thousand tweets per second (TPS), ever second. According to their year in review: http://yearinreview.twitter.com/en/tps.html they hit nearly 9,000 TPS at their peak.
Every single one of those tweets needs to be processed.
With little insight to their infrastructure beyond some of their technical blog posts, we know that at the very minimum the message content will be run through their Abuse/Malware scanner, their URL shortening scanner, and they'll have to look up every single follower. Once they've dealt with re-writing links and are happy the tweet is safe they'll then need to push a copy of the tweet off to every single one of the users followers, and write it to disk.

At the same time they're pushing out firehoses of ever single tweet to search engines and other interested parties, handling many hundreds of thousands of clients demanding the latest tweets for their users, generating web pages of content, returning conversation tracks etc. etc. The whole thing presents a huge technical challenge for scaling, storage and procedural logic.

What Twitter (and companies like Tumbler) are doing is nothing simple on the scale at which they're operating.

2) Here's the bit I don't think you're going to like: Ruby no more stops you from making mistakes than Python, PHP, Java, C++ or whatever your particular flavour is. Anyone that tells you it's impossible to make a mistake in Ruby is lying to you.

No developer is perfect. Every single one makes mistakes, be it through lack of knowledge, typos, insufficient caffeine, misunderstanding the problem, an unexpected element being added to the mix (no matter how idiot proof you make your application, there is always a bigger idiot who will find unexpected fringe cases.), unexpected quirks of interaction between components etc.

It's flat out impossible to make an application without faults.
Here's an article about the guys who write (wrote?) the software that ran the space shuttles, and the extremes that they had to go to to ensure the software contained no bugs on release: http://www.fastcompany.com/node/28121/print
Even with all the effort they went through, they still ended up with bugs, and they're considered industry leading.

I’m not sure this is the right question to ask. At the end of the day, Ruby on Rails is just a Ruby-based web framework. The framework has specific strengths like convention over configuration which allow you to get up and running very quickly. At the same time, those conventions can be overridden if you see fit.

The real question is, is Ruby on Rails the best tool for the job? Some projects have specific requirements such as extremely high throughput multithreading, where Ruby itself is not the best choice. In those cases, some of the newer languages like Go or Elixir would probably be a better choice. Other projects will function perfectly fine on Rails for a very long time. Github is an example of a Rails app that is massively scaled.

The answer to your question, in my opinion, is that Rails itself doesn’t have its own limitations since you can write any Ruby code to extend or change how it works to your heart’s content. Any limitations are going to be more specific to Ruby.

I used to be a Ruby and RoR developer for the longest time. As of 2 years ago, I dropped out and went back to C++ development.

Why?

I did not like the direction Ruby was headed in, both from a technical perspective, and also cultural.

1. Ruby to this day is still hampered by the GIL, though there are variants that blow past this. So, performance is an issue.
2. Ruby on Rails has gone the way of the J2EE back when I was a Java developer. Complicated and overly bloaty.
3. RoR is expensive to scale in comparison with Elixir / Pheonix.
4. Cultural-wise, Rubocop and super short methods have become all the rage in the Ruby community. Rubocop is very annoying, dictating to me how best to structure my code. Excuse me, I’ve been doing this for a long while, and I know how to best structure my own code. Like, for example, when I do chaining, I prefer the “{}” (curly braces) over the “do … end” construct that Rubocop favours. I structure it in a way that enhances readability. Rubocop is dumb and blind… but, many shops have it running in their CI/CD pipelines, and will fail your commit if it turns its nose up at you.
   
   And other Ruby developers get their nickers in a twist if my methods are over 5 lines long. On top of that, they expect unit test coverage for ALL of those methods!!!!
5. Ruby made a significant change in the use of the back-tick, which broke a couple of my Gems. Since my other 18 or so Gems rely on it, all of my Gems are broken for the latest Ruby releases. The back-ticks are used to run cli programs, and they pretty-much disabled them.
   
   I can see having that disabled in a web context (but whatever happened to string tainting????), because of injection issues, but my two gems would never be run in that context. They are command-line only gems — whose sole purpose being to cut other Gems!!!! And let me tell you, you have some serious issues if you need to worry about injections there. As in, you are already screwed, so it doesn’t bloody matter.
   
   I intend to fix this eventually, but I am far too busy to do so now.
6. The latest Ruby has a “JIT” as an option, but instead of doing the really cool thing of leveraging the LLVM like everyone else, they decided instead to spit out C code for a C compiler to compile. Why would they do this??? LLVM brings a lot of powerful optimizing benefits to the table FOR FREE. Like, for example, link-time optimization.
   
   And their choices only resulted in a paltry 3x speed improvement, not a 30x or more improvement, which should be possible.

These are my personal gripes about Ruby, but most likely many of my above points are at least in part responsible for its drop in popularity. There are a few options to Rails, such as Phoenix, written in Elixir, which in turn runs on the BEAM interpreter… yes, you are right. The same one the Erlang uses.

I don’t think Ruby will ever go away completely. Many startups still elect to choose Ruby, if for no other reason that Ruby developers are plentiful and cheap. Cheap in more ways than one, which would explain the recent popularity of something like Rubocop (linter for Ruby) and the insanely short methods and overusing unit testing, which takes a lot of time to run through during your deployments.

Meanwhile, I am doing both C++ and Rust development these days. Maybe some Elixir or Erlang should the opportunity arise. Hell, I’ll even go for Haskell or OCaml.

The Upshot? Ruby totally sucks. ‘Nuff said.

Well they are limiting users now on how many posts they can see each day. I think this is ridiculous cause if Elon wanted to change something for the better then he should have banned all suspicious accounts and people who harass others for entertainment.

Limiting users won't do anything.

I've been scaling web services for years, before there was much guidance on the topic. I've done things the wrong way, and I've done things the right way. Scalability always blows up when a bottleneck is strained too much. After building web services in everything from C, PHP, Perl, Python, Java, .NET, and Ruby, I can tell you that the language has absolutely nothing to do with scalability.

In fact, I'd almost say that Ruby on Rails is the best framework for scaling a service in 2011. Rails makes it incredibly easy to build an application made up of dozens of isolated services. It's basically taking the idea of sharding and applying it to the application, not just the database.

Our current architecture is based on a bunch of smaller services. It's a fantastic architecture; we can independently lock down every service for security and simultaneously partition, load balance, and scale each service. The best part is that individual pieces of the architecture won't bring down the entire framework if it breaks. For example, our invoice PDF exporter seg faults Ruby in 1 out of every 100 requests but it's 100% isolated from all the critical services. Imagine if that were part of our core service.

If you really want to build something that scales, shard your database, storage, and your application. Thankfully, someone finally wrote a book about it too: "Service-Oriented Design with Ruby and Rails".

The answer by Dan is very good so I'm just adding my 2 cents.

The word "switch" carries a lot of bad interpretation with it. When, and if, you reach those same levels of 10 million users, billions of requests, then every solution will be different.

Back then you didn't have much choice. Node didn't exist. JRuby was not ready yet. Go didn't exist. Rust didn't exist. You could try pure Java, pure C even, maybe dabble into Erlang to blow your mind.

But once you experimented Ruby it's hard to go back. And Scala was a good enough pick for the back end concurrent message broadcast system. As far as I know the Rails front end was not replaced, at least not back then.

It makes sense to replace specific pieces and make new architectures to try to squeeze as much juice as possible when you have infrastructure bills exceeding hundreds of thousands of dollars.

Many people want to make this a controversy of language wars. This is just naive. Good programmers are not loyal to ideologies, we are problem solvers and we will use best of breed. That means a conscious balance between productivity, performance, total cost of ownership, and so on.

A dear friend of mine once said, “Ruby on Rails is so opinionated that you can basically poop on the keyboard and it’ll deploy.” I responded with enthusiasm, and he shook his head and said, “But now, try and scale it.” Hence your question: you want an alternative to Ruby on Rails that is more performant. I’ve got just what the doctor ordered: Phoenix LiveView.

It’s an opinionated web framework, very similar to Rails. It uses Elixir, which even has similar syntax to Ruby. The difference is threefold:

1. Elixir is functional, rather than OOP.
2. Elixir uses the BEAM, resting on the absurdly robust and performant OTP framework.
3. Phoenix Liveview has a stateful front end that uses websockets, which makes it even faster.

The immutability of data structures that you get from functional programming lends itself to concurrency because there’s less shared mutable state, so you can create a bazillion processes with less risk. The BEAM takes full advantage of this, and then LiveView sits on top of that as an opinionated web framework. You can poop on the keyboard and it’ll deploy and scale.

Given the increasing popularity of functional programming, a lot of Ruby shops are switching to Elixir. A lot of the Ruby shops in my city are already converting to Elixir because of the huge performance gains and ease of learning Elixir’s syntax, due to its similarity to Ruby. I can’t tell you how many times I’ve spoken with Elixir devs who said something that started with, “Yeah, we used to be a Ruby shop, but it was kind of slow…”

That’s another good thing about Elixir: if you want to try out functional programming but you’re scared of parentheses (Lisp) and things like Haskell and Erlang seem too arcane, Elixir is a friendly face. Personally, I prefer Clojure, but Elixir ain’t half bad.

I think pointing to solid resources is the only real way to answer this question without typing a book. So, here's another good one for you.

http://railslab.newrelic.com/scaling-rails

Of course, with rails 3 out a lot of things has changed.

The biggest problem I usually see with Rails scalability issues is very poorly implemented applications that rely to heavily on the built in bits and pieces doing their thinking for them. Hence, they end up with poorly architect applications.

So, in summary, the real scale issues actually have very little to do with Rails itself as with the overall application architecture not being scalable.

I think your question sets up a false premise. Ruby on Rails for a while virtual stood alone in being a framework that had an extremely low cost of entry. Rails is a language that can be quickly and intuitively learned. The Rails ecosystem had great support from a number of startups, all of whom were contributing.

That ecosystem has not really went away, but it has been joined by NodeJS and other frameworks.

So while continuing absolute growth, the relative growth of Rails (or if you will market share) has appeared to decrease.

What you’re really seeing is a shift in the corporate space to other frameworks other than Rails. That’s mostly due to the relative comfort with more complex base syntax (think C# feeling comfortable with typescript). You also have some major corporate software players, ex: Microsoft, putting comparatively more effort into other frameworks (ex: Typescript).

Learning to develop a modern web application is intimidating. Ruby on Rails makes it much lighter and more enjoyable. It includes all you need to build powerful applications. Many start-ups have called into questions asking the quickest and easiest way to develop their web apps.

These start-ups and established enterprises have come to the determination that when developing applications designed and engineered to be extradited on the Internet, Ruby on Rails has been and probably is the best choice, at least for another decade. To compare with PHP, Ruby offers much more scalability and performance with a speed of execution rate being much higher.

Does Ruby On Rails make any difference, really?

Do not take Ruby on Rails for a programming language; it is only a web framework. Ruby is the programming language behind the Ruby on Rails framework, and compared to PHP; PHP is a programming language used to write PHP applications.

As a programming language, Ruby is quite a great language. Unlike PHP, Ruby is an Object-Oriented Program from the ground up. Its code is very brief and powerful. Gems (extensions) enable you to engage in needed functionality. After coding in Ruby, you’ll find coding in PHP (or anything else really) rather tedious.

Ruby on Rails is an open source software, hence not just is it free to use; you can also help make it better.

Many programmers operating with Rails tire from creating on platforms like .NET and Java, which isn’t quite as good as Rails when it comes to Rapid web development frameworks.

The greatest reward of using Ruby over Java or PHP or that extent any other programming language is that you can achieve tasks by coding less.

• Ruby on Rails is a dynamic framework, helps in fixing bugs faster and accelerates the entire development process. Ruby’s code can be interpreted and does not need compilation. Nevertheless, Java code requires being compiled before interpretation.
• Ruby is more advanced and more capable of being changed: it supports many different programming paradigms, whereas Java restricts to Object-Oriented Programming.
• Ruby has a briefer syntax and frequently requires much, much less effort to get the same tasks done as they would need in Java. Ruby on Rails offers flexibility and readability while Java offers better application performance. Java follows a strict ‘C’ syntax in coding while Ruby on Rails (ROR) allows the programmer to omit a few codes.

Benefits with Ruby on Rails:

It is possible that no one would even know about the advantages for Ruby if it were not for Rails itself.

Some individuals like to disparage Ruby by saying that it is “so well-off for Ruby” with its “knight in shining armour, that is called Rails” and that with the absence of Rails, “Ruby would be completely irrelevant.”

I would not articulate with certainty whether or not that is true, but I do know that it would be a huge dishonour if the world missed out on such a brilliant language.

The fact is that the author of Rails picked Ruby on purpose by design, and his ‘crazy’ bet paid off with huge interest. What he came across back then, lots can experiment and learn today.

Ruby on Rails is helpful beyond question for your web apps, its benefits to scalability and over the long run, it saves your time and money in the ever-changing world.

Business Labs has an army of creative web designers and developers. We have a very privately held process for screening designers and tech geeks to join the clan. Business Labs verifies the talent with great diligence and so with our company, you get the best.

It was smart, but I would say the decision probably was not entirely based on a pure platform choice. By the way, the way the question is framed is somewhat incorrect, because RoR is a webapp framework built on Ruby (the language), and Java is a language, not a webapp framework.

That said, this decision was smart for the following reasons:

1. The important choice was Lucene, a search engine library written in Java. This is the premier open source search technology today. We use it at Etsy, Facebook uses it for its message search, and many more top adopters as well.
2. They already had extensive experience with running and tuning the Java Virtual Machine, from their Scala infrastructure (which runs on the JVM of course).
3. The performance gains were way more than 30%:

Now that the system is up and running, we are very excited about the results. We estimate that we’re only using about 5% of the available backend resources, which means we have a lot of headroom. Our new indexer could also index roughly 50 times more Tweets per second than we currently get! And the new system runs extremely smoothly, without any major problems or instabilities (knock on wood).

More on this here:
http://engineering.twitter.com/2010/10/twitters-new-search-architecture.html

• Ruby has a simple syntax and comprehensible semantics that makes it easy to adopt.
• With Rails, you can build interesting business features and products really fast.
• RoR is centered around this structural concept which makes grasping object-oriented principles like SOLID a piece of cake.
• Ruby on Rails allows you to focus on the task rather than the language.
• As Rails specifics allow for quick coding, the fast development of quality software becomes real.
• Ruby on Rails development is more cost-efficient than other options because even junior-to-middle-level RoR programmers can set up a proper back end.
• Ruby on Rails allows for robust error trapping, which enhances the stability of the software. When properly leveraging the framework, you can scale on the fly and write business logic with ease.

Everything, at first. Twitter, Airbnb and many other startups have used Ruby on Rails for their entire website, backend tools, payments integrations, emails templates… anything and everything that Rails can do.

When you're a small startup moving fast it often makes sense to use an agile framework like Rails to build features quickly and scale them. As requirements get more complex many startups will start extracting services from their Rails monolith. These services could still be Rails or Sinatra apps, but are more commonly Java, Scala (or other JVM languages), Node or other frameworks with strengths that complement Rails.

Rails is probably not actually the performance bottleneck in most real world applications. Waiting on external api’s and databases is where web apps spend most of their time. ActiveRecord is pretty chatty by default a little time with a tool like new relic and the bad chatter can be removed pretty easily.

There are a bunch of cool alternatives to rails if that’s your jam.

1. phoenix - it is written in elixir and can handle some pretty crazy concurrency. Phoenix liveview is one of the craziest things you will see
2. Buffalo - written in go. Being a compiled language being able to build a static binary shove it in a container aligns really well with the way modern container infrastructure
3. next.js - built on top of react it adds server side rendering and a lot of sanity to building a react app. It can be paired with a JavaScript server like express or one of the lighter weight options for a full stack setup. Pairing ES6+ syntax and typescript JavaScript is not horrible.

Since you want a comparison with php/java, it is more faster to develop than java and is more structured/maintained than php.
By the time you are done with configuration in a java Web framework, your rails app would be running with many features and as the application grows in size, it will not grow monstorous in size like various php apps.

That said, it has got quirks of its own and if you do not follow the practices laid down by the rails framework, be prepared to end up banging your head against a wall.
The well laid structure of this framework is the basis or inspiration of many such frameworks in java(play) or php(cakephp) to name a few.