10 ms·

Is Ruby Too Slow for Web-Scale?

84 points by nateberkopec 9y ago

janvdberg 9y ago
Obligatory link whenever this discussion appears: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...
davehtaylor 9y ago
It's web scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- pdkl95 9y ago
  "If you're willing to suffer complex code for performance, why not just write an nginx module in C?" "node.js is is the most bad-ass rock star tech to come out since Ruby On Rails" https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg ... "What was that last part again? I could have sworn you just said Lisp" (Yes, performance and scalability are complicated. Different solutions will be appropriate for different situations.)
tomc1985 9y ago
If the headline ends in a question mark the article is probably speculative
sergiotapia 9y ago
There's more problems with Ruby than just speed (but it is objectively slow). Most of them caused by Rails to be honest. But who's realistically writing webapps using Ruby without Rails? There are much better alternatives today that build upon the strengths of Ruby and leaves behind it's weaknesses. As processors become more about multi-processing, languages that leverage that are going to gain popularity.
- Dobbs 9y ago
  Which alternatives do you recommend?
  - sergiotapia 9y ago
    Leverage your Rails knowledge and jump onto greener pastures with Elixir/Phoenix.
- flavio81 9y ago
  > But who's realistically writing webapps using Ruby without Rails? Sinatra is very popular...
- barrkel 9y ago
  It's faster than Python, at least by my most recent personal benchmarks.
weatherlight 9y ago
My issue with Rails/Ruby (I've been Ruby developer for 4 years) is people have this tendency to write monoliths and crazy unmaintainable code. I wish we wrote our stuff in a functional way like Elixir.
- johnbellone 9y ago
  That is going to be an issue with any project with many developers that uses a popular framework irregardless of the language. It is very difficult to keep quality code hygiene with that many people touching a project. The key is compartmentalization: multiple applications, libraries, etc.
- ravenstine 9y ago
  Yes, this, and mostly this. I don't know exactly where this comes from, but then again I haven't been a professional for that long. Maybe it's because so much of Ruby web development is centered around Rails that someone just assumes that every new thing should just go into their existing Rails app as another model, another controller, another view, etc., instead of considering whether or not a whole domain of code could belong in another codebase or at least another process besides the same one being used by the Rails server. All the TDD in the world isn't going to prevent someone from making a bunch of poor choices around engineering or design patterns. Caching strategies can help, but they can also become crutches. At worst, they end up causing a lot of confusion when something isn't getting "updated", and some developer used a bunch of fragment caches triggered by different things. In my experience, it's much easier to forego TDD, only write important tests, and try to divide things out into separate projects where it makes sense. That way bugs can be quickly squashed and new features can be added quickly(very little time wasted learning a bunch of complex mechanisms), unique components of a larger system can be updated & rolled back pretty independently, and you get more value out of your testing than most tests I've seen in Rails monoliths(often foolishly testing Rails features themselves). This can be done through gems or even completely separate Rails/Node/whateva applications/APIs that communicate(remember, sockets are pretty fast). If you must have a monolith, at least consider what things should be "first class" and whether or not you can afford to have things get processed in the background. Async is easy these days. I love what Rails has done for me and what it represents, but I've become disenchanted by the lack of deep thought that it's fostered in new developers, which includes me where I was not that long ago.
didibus 9y ago
Is web scale like the internet tax?
cplanas 9y ago
No. If it's good enough for companies like Zendesk or Shopify, is probably good enough for you. And if your "web" somehow gets to the point in which Ruby/RoR can't make it scale, congratulations for becoming the next Twitter and then you can migrate to something else.
- RangerScience 9y ago
  Fun fact: Twitch (which probably had the most ridiculous month-over-month growth in recent years, possibly since TwitteR) is in Rails... And my favorite, Raverly (~7 mil user accounts), is done by two engineers (or was, not too long ago - it's hard to get numbers on these things). Two! Talk about developer efficiency.
  - hu3 9y ago
    Twitch is moving all they can to more efficient technologies such as Go. At that scale every CPU cycle counts and any delay is perceived by users. "We use Go at Twitch for many of our busiest systems. Its simplicity, safety, performance, and readability make it a good tool for the problems we encounter with serving live video and chat to our millions of users..." - blog post a year ago. Do your research before spreading old news.
    - RangerScience 9y ago
      I did my research. My research indicated that Twitch got set up in Rails, and first transitioned their chat client out of Ruby land. I was not able to determine when Twitch began doing this, but seeing as their first major growth spurt was on launch, seems unlikely it was before they had to scale Rails to a substantial degree. I was also not able to determine what else they've switched over. Old news is still relevant information, particularly when that news is "went from zero to ~10m on tech X".
      - hu3 9y ago
        http://engineering.twitch.tv/ http://engineering.twitch.tv/ says: "Powered by Go" with zero mentions of Ruby. Saying twitch "is in Rails" in 2017 is disingenuous to say the least.
ravenstine 9y ago
No. How about this: understand what the hell you're doing. For 99% of the web, 531 requests a second is beyond what you need. Not everything on the web needs to respond to 7000+ requests a second. In fact most of it doesn't. Heck, most of it doesn't need to respond faster than 1 second. In my experience, most of the poor performance in Ruby web applications is caused by trying to shove too many operations into the same process and making all data "first class". This is probably in part because Rails for years didn't include a built-in jobs system. The only thing "web-scale" means is that something serves HTTP requests through the web in a way that people find useful. If so, then any language that can create sockets is potentially web-scale, including COBOL. Beyond that requirement, there's no such thing as "web scale". All web companies like Facebook, Amazon, Twitter, Apple, etc., operate at different scales and adjust to their own needs accordingly.
- tomc1985 9y ago
  Article is obnoxiously long and borderline idiotic. Dude spends way too long talking about way too much stuff, and in scanning the words all I saw was fluff. TL;DR, nonsense, typical Medium blog
- BlackjackCF 9y ago
  Yup. If Ruby is good enough for Github, Soundcloud, and many many other large-scale companies, Ruby is good enough for anyone. Knowing what the hell you're doing is half the battle. I've heard places convert from a Ruby stack to Java, and a lot of it was just to hide the fact that the programmers didn't know what the hell they were doing.
  - zer00eyz 9y ago
    > I've heard places convert from a Ruby stack to Java Twitter. And for good reason. The problems that Github and Soundcloud have aren't related to their web front ends. Bandwidth, storage and a host of other issues are probably more front and center. Twitter has these same problems but for a different set of reasons. Their web front ends are doing a hell of a lot more work relative to the amount of data coming and going. How big is a tweet vs a repo vs a song. Yes they are all on the web but these three companies could not be more different. > I've heard places convert from a Ruby stack to Java, and a lot of it was just to hide the fact that the programmers didn't know what the hell they were doing. Why go from ruby to java? Because you want to invest in an ecosystem that is far more robust and far richer. You don't want a pile of ruby programers off in a corner doing their own thing with bunch of containers while you HAVE to hire java guys to deal with the large scale problems that organizations of a certain size face. At the time twitter made this choice it was the ONLY choice to make. They didn't have a list of good options that we have today (Go, Scala, Haskle). The reality is that they would STILL probably choose java because it is still easier to find talent and it still has a richer background. Lets make a comparison here... PHP vs RUBY, and lets talk about the devs. I am hard pressed to find a decent PHP dev who won't throw PHP under the bus (or out the window) when they get outside what it is good for. I am hard pressed to find a ruby dev who doesn't fully believe that the solution is always more ruby. There are plenty of good ruby devs (great ones in fact) who swear that ruby is the only way!
overshard 9y ago
Clickbait title aside, use whatever language will make you and your team most productive to launch your product, if you run into issues once you hit it big concern yourself with "web-scale" then. In 15 years of coding I've run into extremely few web dev projects that tree profiling to find the issue then caching hasn't solved.
lxe 9y ago
> So, if we’ve already got ~40 milliseconds of round-trip network latency in the first place, will our users be able to perceive the difference in a web application which renders a response in 1 millisecond or 100 milliseconds? That is, one application will take 41 milliseconds in total and the other 141. Yes. Definitely. Absolutely. The users will perceive the difference. This is a slowdown of over 3X. If you're loading resources (in a variety of synchronous batches of asynchronous requests) for your web application, these slowdowns compound significantly. Of course, the design of the web application plays a huge role, but assuming the worst (every user action triggers a request), a 3X slowdown is perceived by a variety of users.
- zer00eyz 9y ago
  I think your making a strong point here, that might not get the attention it deserves. > asynchronous requests Because we don't live in a world where one user loads one page and then loads the next one (and if they do we should be talking about how your not using cached static content). If I can do the work in 20ms, and it takes 100ms with framework overhead what happens when these start stacking up? Not only do those things impact the user they impact your server... every ms that it has to maintain that connection, do work is one more ms that it isn't doing work for someone else.
- nateberkopec 9y ago
  I cited decades of human-computer interaction research that disagrees with you. EDIT: also, that paragraph is purely discussing the response times for producing the HTML document of a web application, not, say if you added 100ms lag to every JS response (which would compound, like you say).
  - zokier 9y ago
    I think one of the main datapoints is the classic quote from Amazon that 100ms of added latency reduces sales by 1%. There are similar comments floating around from other big players (Google etc) too. edit: this is the best link I could find for now: http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it http://highscalability.com/latency-everywhere-and-it-costs-y...
alberth 9y ago
I realize many will say Ruby is fast enough. But if you're a web developer, why WOULDNT you just develop your next net new project in Phoenix/Erlang instead of Rails/Ruby? Phoenix has most of the development bedofits of Rails, yet way better performance and scalability. Seems like a win-win. You get a Rails like development environment without any downside of perf.
- sergiotapia 9y ago
  I've dropped Rails for new projects and I'm using Elixir/Phoenix exclusively now. Too many benefits to list out here, but probably my favorite feature is Elixir's pattern matching. Also running my test suite in 1.4 seconds always makes me smile.
- Daishiman 9y ago
  Because Phoenix's library ecosystem is probably 3% of the size of Rails'.
  - weatherlight 9y ago
    you also have 30 years of erlang libraries... OTP is the reason why you'd switch to elixir/otp
    - Daishiman 9y ago
      The number of Erlang users is a very, very small percentage of Rails users. OTP is great, but wiring up API connectors and auth systems and serializers and whatnot still takes up time.
- deleted 9y ago
  [deleted]
- goseeastarwar 9y ago
  You answered your own question. There’s no need to switch, because ruby is fast enough (and requires no additional training to continue using it).
pmontra 9y ago
> Languages aren’t dying based on their concurrency or performance features alone. I'm afraid this is going to be more and more about which languages run on serverless platforms. Those companies decide which languages win. Example: AWS Lambda is still Nodejs, Python and Java. We can hack about any language into it (I did with mruby), if we make Python or Nodejs exec it, but it's not worth the effort.
jaequery 9y ago
i dont know why people fail to understand. most of the slowness is not the language but the code. for instance, raw php is really fast but apps like magento and wordpress slows it down to a crawl, more slower than a typical rails app. depends per project but usually the slowness comes mostly from the abstraction with the db layer. where this means the latency to the db needs to be factored in to the benchmarks as well as to see if there are any lighter ORMs that can be used.
tomc1985 9y ago
Watch as the language and framework vultures descend on this thread...
- flavio81 9y ago
  no, i'm waiting for the vultures that think that every language and every platform is equal.
avitzurel 9y ago
I want to add my POV here because I've been working with Rails for 6 years and recently changed jobs and moved to Python and Node.JS (and been working with Golang for the last 3 years). One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR. The way you can start a project in a second is amazing, the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else. Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. From Authentication to Authorization and all the community around these. Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. Most of the slowness you are experiencing in Rails and Ruby apps is by doing poor engineering, not by Rails or Ruby itself. Big Surprise... If you query 1000 rows and bind them to the controller things will be slow. There are things that are natively slower, JSON parsing and marshaling for example is one. It's much slower than Go for example but it's so much easier and for 99% of us, this is what matters. I don't get the hate that Ruby and Rails are getting. Really don't.
- avitzurel 9y ago
  I said it before in my streams many times [1] This is a classic case of weighing solutions against other solutions. When you do that the one with the most features or the fastest will always seem the best. But, you need to weigh the solutions against your problem. Your problem is time-to-market. Your problem is development time. Your problem is software reliability. Your problem is finding great engineers to do great work. When that's your problem. Ruby and Rails are great solutions. Not good. Great solutions. Show me an express app that is as monolithic as some Rails apps and I will show you how Node.js halts to a crawl. [1] https://twitch.tv/kensodev https://twitch.tv/kensodev EDIT: Typo
  - avitzurel 9y ago
    Yes. It's easier to find people with Javascript experience to work on your Node.JS app. But are they as good as the engineer doing Ruby for 6 years? Are they as good as someone doing Python for the last 10 years? I am not going to try and answer these, it will be idiotic but all of these articles and some of the thrust behind leaving Ruby and these articles are just driven by the wrong reasons.
flavio81 9y ago
Website says "The majority of web applications handle far less than 1000 requests per second." The benchmark provided (TechEmpower Benchmark) measure the amount of requests served, but these requests are for rather easy tasks like fetching data from a SQL database and serving it. Or doing JSON serialization. Drop in a more alghoritmically-complex and/or general-purpose task (say, compress this file using GZIP before saving it on your server), and then you will feel the speed (or slowness) of your platform. And here perhaps you couln't hit the magical "1000 requests per second" benchmark. Objectively, Ruby implementations (on the canonical Ruby MRI implementation) are slow. Sometimes even 100x slower than C. Taking a deep look at these graphs, where 1x is C's performance under GCC: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-... Ruby MRI is typically 20x to 50x slower than C. Looking at the graph is revelaing, but in any case, for other dynamically-typed, dynamically-linked languages, here are other typical figures for comparison (from the graph, relative to C/GCC, lower numbers better). Ruby MRI* 20x to 50x Python 3 Similar to Ruby MRI Racket 6x to 12x ECMAscript (Node.js/V8) 7x to 10x Common Lisp (SBCL compiler) 2x to 5x For statically-typed languages: Haskell (GHC) 2x to 9x Java (latest official JVM) 1.5x to 3x Swift and Go similar to Java C# (under .NET Core latest) similar to Java Rust <1x to 2x C++ (g++ compiler) equal to slightly slower than C C under GCC 1x * JRuby, as the graph can show, doesn't help too much, and sometimes can be 2x to 7x slower than Ruby MRI! http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=jruby http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... At the end, for Ruby I would take the similar stance I would take with Python --- if I use it, it's because I like it. For example, I like using Python better than Js(under Node.js). However if i was building a system that will demand performance, i'd look to other languages/implementations.
- RangerScience 9y ago
  Fun fact: MRI is actually designed more around memory efficiency than speed, because it's major funders are Japanese automobile companies, and Heroku; who (apparently?) care more (sometimes way more) about memory. It's also (apparently) why MRI has such a fast startup time compared to similar languages and other Ruby implementations.
mnm1 9y ago
The article isn't compelling. I'd argue most scripting languages, including Ruby are too slow for many situations. The author is thinking of one request. What if I have multiple Ruby APIs to hit? 100ms for each one adds up quickly. The frontend being a mess of many megabytes and taking 15 seconds to load is also not an excuse to make the backend shitty. Fix the front end, then the backend speed will matter. Yes, there are other considerations, but these days there are plenty of languages to choose from for the back end that offer memory management and instant reloading of code like Ruby and other scripting languages while being quite a few times faster. They also offer a chance to escape with a decent app in case the company you're working for hired a bunch of idiot architects that put in database wrapper code that takes 10x as long as the database itself to run and you don't have time or resources to rewrite the last four years worth of work in a faster language with a proper architecture. I personally cannot see choosing Ruby or any similar language (PHP, Python, JS) in the future for webdev stuff.
- schneems 9y ago
  > What if I have multiple Ruby APIs to hit? Then hit them with multiple concurrent threads and move on.
  - flavio81 9y ago
    ... do you think available memory and CPU time do not decrease when you spawn more threads?
    - schneems 9y ago
      Use threads. They exist. Use em'. Know what threads are really good at? Hiding IO time. They're like REALLY good at it. When a thread is blocked on IO, it's not spinning your CPU. So is the thread "free"? No. Is it pretty cheap compared to re-writing an app in another lang? Yes.
  - mnm1 9y ago
    And if I need to hit them in serial?
claudiug 9y ago
ruby is not slow compare with some other languages(python, js, php) but there are some other languages there, with better PR, and better ecosystem: - kotlin - netcore - swift - go All of them have a rails framework clone :) ruby needs, JIT, concurrency, and some crystal magic
tracker1 9y ago
There are more issues than just raw performance, or only raw performance. Right now, I'm working for a web services company where the vast majority of our work is via an API with a limited range of request types. We have external(locally cached) and internal data sources that all have to be queried, and dealt with before the logic can work and a response can be returned. We're currently niggling over a few ms here, and a few there. Balancing the cost of adding more servers to distribute load. Migrating from colocation to cloud hosting in order to scale more seamlessly (iirc, over 150% growth yearly or more). Our SQL database has been a big bottleneck, moving heavy loads out of SQL and into more appropriate separate data stores. Just because it's only an extra 100ms, doesn't mean it doesn't matter, as it's not the only link in the chain. I would never, for example use rails for an API service... it's too expensive on top of everything else. Right now we have a fair amount of C#, a bit of Node, and may consider some go for future use in pieces. It comes down to picking the right things... It also depends on what/where you're using the technology.
deleted 9y ago
[deleted]
throwaway47861 9y ago
The article tries a little too hard to defend Rails. It has very legitimate scaling issues and they are well-documented. The author is also way too pessimistic about newer stacks and is demonstrating a grumpy-old-fart-like attitude saying that "new stacks will find new ways to jam CPUs or I/O stacks". Might be true, might be not. It's not a fact. I also get a vibe that the author exaggerates the problems with newer stacks. And it contains way too much assumptions in the case you switch stacks. So he says that if you migrate to Phoenix or Node.JS, then: (1) The load on the DB will not change. True, but Elixir has a cache directly inside the VM so the I/O costs for a _separate_ memcached server are almost fully eliminated right from the get go. (EDIT: in my not-so-big Elixir/Phoenix experience so far, Ecto is still faster than ActiveRecord; but I do still admit the DB load is pretty much the same.) (2) 20k RPM doesn't mandate 50 engineers. I've been in a team managing an app with a 12k RPM with only two senior devs. We were just fine for the 2 years I've been there. (3) New stacks slows down development. If you don't hire juniors, this is only true for the first 2-4 weeks. I've been fully onboarded in an umbrella Elixir app containing Phoenix and GraphQL endpoints, and a total of 6 apps, for 3 weeks. I surpassed my Rails development speed for 3 weeks. Very, very bogus assumption here. Assuming that switching a stack means you do cargo-cult engineering is disrespectful. Sure he might have seen it 200 times, doesn't mean the whole world does it. As much as I love Elixir, I was honest with myself and had to write a few small microservices in Go, and I am glad that I did because it was a perfect fit. I have a huge respect for Nate Berkopec and was following him closely for a while. He's a really awesome engineer. But that essay left me with a bitter taste of "my constultancy might be endangered, time to badmouth the new stacks". Why do I think so? Again, too many negative assumptions about the new stacks. No real argument, just negativity. Does Phoenix pose its own WTF moments when you migrate from Rails (or any other framework)? Sure! It absolutely does. No tech stack is perfect. The end result however is increased developer productivity -- speaking about myself and apparently thousands more out there on the internet who claim the same -- and less server costs. And these both were measured over time. If you want to use Rails, do so -- it is the perfect choice for a plethora of projects. But there is no need to badmouth alternatives especially if you don't have a case and your entire argument is comprised of negative assumptions about those alternatives. I am disappointed with the author.
passer-by-123 9y ago
The push to new technologies are not based solely on performance. Rust brings a type-safe and memory-safe guarantees. Elixir brings concurrency and functional concepts that lead to clearer code. Even node.js has the benefit of ubiquity. Even if you want to debate those claims, those are perceived reasons for people adopting those platforms - just ask them. Having a more scalable and performant platform is just a nice bonus. It is also misleading to think that performance impacts only the user experience. No, it drastically affects the developer experience too! Over the years the Ruby community has struggled with performance issues. Your application takes a long time to boot? Let's introduce a tool like Spring that works only half of the time. Your application cannot handle blocking requests? Let's push our whole design towards jobs. View rendering is slow? Let's add cache layers over cache layers (aka russian doll caching) and then good luck debugging cache expiration issues. Even running tests is unnecessarily slow in Rails. When one test is querying the database, another test should be running. I am not talking about multi-core concurrency, just simple IO-based concurrency. Extra points if a language can give me CPU concurrency too! Those are long term issues that impact the developer productivity and increase the maintenance burden on your teams. That's without taking into account other issues prominent in the Rails community, such as abusive use of monkey patching and global state. I moved away from Rails not because I wanted performance but because I wanted simplicity and long-term productivity.

84 points by nateberkopec 9y ago

Obligatory link whenever this discussion appears: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...

davehtaylor 9y ago

It's web scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs

pdkl95 9y ago
"If you're willing to suffer complex code for performance, why not just write an nginx module in C?" "node.js is is the most bad-ass rock star tech to come out since Ruby On Rails" https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg ... "What was that last part again? I could have sworn you just said Lisp" (Yes, performance and scalability are complicated. Different solutions will be appropriate for different situations.)

tomc1985 9y ago

If the headline ends in a question mark the article is probably speculative

sergiotapia 9y ago

There's more problems with Ruby than just speed (but it is objectively slow). Most of them caused by Rails to be honest. But who's realistically writing webapps using Ruby without Rails? There are much better alternatives today that build upon the strengths of Ruby and leaves behind it's weaknesses. As processors become more about multi-processing, languages that leverage that are going to gain popularity.

Dobbs 9y ago
Which alternatives do you recommend?
- sergiotapia 9y ago
  Leverage your Rails knowledge and jump onto greener pastures with Elixir/Phoenix.
flavio81 9y ago
> But who's realistically writing webapps using Ruby without Rails? Sinatra is very popular...
barrkel 9y ago
It's faster than Python, at least by my most recent personal benchmarks.

weatherlight 9y ago

My issue with Rails/Ruby (I've been Ruby developer for 4 years) is people have this tendency to write monoliths and crazy unmaintainable code. I wish we wrote our stuff in a functional way like Elixir.

johnbellone 9y ago
That is going to be an issue with any project with many developers that uses a popular framework irregardless of the language. It is very difficult to keep quality code hygiene with that many people touching a project. The key is compartmentalization: multiple applications, libraries, etc.
ravenstine 9y ago
Yes, this, and mostly this. I don't know exactly where this comes from, but then again I haven't been a professional for that long. Maybe it's because so much of Ruby web development is centered around Rails that someone just assumes that every new thing should just go into their existing Rails app as another model, another controller, another view, etc., instead of considering whether or not a whole domain of code could belong in another codebase or at least another process besides the same one being used by the Rails server. All the TDD in the world isn't going to prevent someone from making a bunch of poor choices around engineering or design patterns. Caching strategies can help, but they can also become crutches. At worst, they end up causing a lot of confusion when something isn't getting "updated", and some developer used a bunch of fragment caches triggered by different things. In my experience, it's much easier to forego TDD, only write important tests, and try to divide things out into separate projects where it makes sense. That way bugs can be quickly squashed and new features can be added quickly(very little time wasted learning a bunch of complex mechanisms), unique components of a larger system can be updated & rolled back pretty independently, and you get more value out of your testing than most tests I've seen in Rails monoliths(often foolishly testing Rails features themselves). This can be done through gems or even completely separate Rails/Node/whateva applications/APIs that communicate(remember, sockets are pretty fast). If you must have a monolith, at least consider what things should be "first class" and whether or not you can afford to have things get processed in the background. Async is easy these days. I love what Rails has done for me and what it represents, but I've become disenchanted by the lack of deep thought that it's fostered in new developers, which includes me where I was not that long ago.

didibus 9y ago

Is web scale like the internet tax?

cplanas 9y ago

No. If it's good enough for companies like Zendesk or Shopify, is probably good enough for you. And if your "web" somehow gets to the point in which Ruby/RoR can't make it scale, congratulations for becoming the next Twitter and then you can migrate to something else.

RangerScience 9y ago
Fun fact: Twitch (which probably had the most ridiculous month-over-month growth in recent years, possibly since TwitteR) is in Rails... And my favorite, Raverly (~7 mil user accounts), is done by two engineers (or was, not too long ago - it's hard to get numbers on these things). Two! Talk about developer efficiency.
- hu3 9y ago
  Twitch is moving all they can to more efficient technologies such as Go. At that scale every CPU cycle counts and any delay is perceived by users. "We use Go at Twitch for many of our busiest systems. Its simplicity, safety, performance, and readability make it a good tool for the problems we encounter with serving live video and chat to our millions of users..." - blog post a year ago. Do your research before spreading old news.
  - RangerScience 9y ago
    I did my research. My research indicated that Twitch got set up in Rails, and first transitioned their chat client out of Ruby land. I was not able to determine when Twitch began doing this, but seeing as their first major growth spurt was on launch, seems unlikely it was before they had to scale Rails to a substantial degree. I was also not able to determine what else they've switched over. Old news is still relevant information, particularly when that news is "went from zero to ~10m on tech X".
    - hu3 9y ago
      http://engineering.twitch.tv/ http://engineering.twitch.tv/ says: "Powered by Go" with zero mentions of Ruby. Saying twitch "is in Rails" in 2017 is disingenuous to say the least.

ravenstine 9y ago

No. How about this: understand what the hell you're doing. For 99% of the web, 531 requests a second is beyond what you need. Not everything on the web needs to respond to 7000+ requests a second. In fact most of it doesn't. Heck, most of it doesn't need to respond faster than 1 second. In my experience, most of the poor performance in Ruby web applications is caused by trying to shove too many operations into the same process and making all data "first class". This is probably in part because Rails for years didn't include a built-in jobs system. The only thing "web-scale" means is that something serves HTTP requests through the web in a way that people find useful. If so, then any language that can create sockets is potentially web-scale, including COBOL. Beyond that requirement, there's no such thing as "web scale". All web companies like Facebook, Amazon, Twitter, Apple, etc., operate at different scales and adjust to their own needs accordingly.

tomc1985 9y ago
Article is obnoxiously long and borderline idiotic. Dude spends way too long talking about way too much stuff, and in scanning the words all I saw was fluff. TL;DR, nonsense, typical Medium blog
BlackjackCF 9y ago
Yup. If Ruby is good enough for Github, Soundcloud, and many many other large-scale companies, Ruby is good enough for anyone. Knowing what the hell you're doing is half the battle. I've heard places convert from a Ruby stack to Java, and a lot of it was just to hide the fact that the programmers didn't know what the hell they were doing.
- zer00eyz 9y ago
  > I've heard places convert from a Ruby stack to Java Twitter. And for good reason. The problems that Github and Soundcloud have aren't related to their web front ends. Bandwidth, storage and a host of other issues are probably more front and center. Twitter has these same problems but for a different set of reasons. Their web front ends are doing a hell of a lot more work relative to the amount of data coming and going. How big is a tweet vs a repo vs a song. Yes they are all on the web but these three companies could not be more different. > I've heard places convert from a Ruby stack to Java, and a lot of it was just to hide the fact that the programmers didn't know what the hell they were doing. Why go from ruby to java? Because you want to invest in an ecosystem that is far more robust and far richer. You don't want a pile of ruby programers off in a corner doing their own thing with bunch of containers while you HAVE to hire java guys to deal with the large scale problems that organizations of a certain size face. At the time twitter made this choice it was the ONLY choice to make. They didn't have a list of good options that we have today (Go, Scala, Haskle). The reality is that they would STILL probably choose java because it is still easier to find talent and it still has a richer background. Lets make a comparison here... PHP vs RUBY, and lets talk about the devs. I am hard pressed to find a decent PHP dev who won't throw PHP under the bus (or out the window) when they get outside what it is good for. I am hard pressed to find a ruby dev who doesn't fully believe that the solution is always more ruby. There are plenty of good ruby devs (great ones in fact) who swear that ruby is the only way!

overshard 9y ago

Clickbait title aside, use whatever language will make you and your team most productive to launch your product, if you run into issues once you hit it big concern yourself with "web-scale" then. In 15 years of coding I've run into extremely few web dev projects that tree profiling to find the issue then caching hasn't solved.

lxe 9y ago

> So, if we’ve already got ~40 milliseconds of round-trip network latency in the first place, will our users be able to perceive the difference in a web application which renders a response in 1 millisecond or 100 milliseconds? That is, one application will take 41 milliseconds in total and the other 141. Yes. Definitely. Absolutely. The users will perceive the difference. This is a slowdown of over 3X. If you're loading resources (in a variety of synchronous batches of asynchronous requests) for your web application, these slowdowns compound significantly. Of course, the design of the web application plays a huge role, but assuming the worst (every user action triggers a request), a 3X slowdown is perceived by a variety of users.

zer00eyz 9y ago
I think your making a strong point here, that might not get the attention it deserves. > asynchronous requests Because we don't live in a world where one user loads one page and then loads the next one (and if they do we should be talking about how your not using cached static content). If I can do the work in 20ms, and it takes 100ms with framework overhead what happens when these start stacking up? Not only do those things impact the user they impact your server... every ms that it has to maintain that connection, do work is one more ms that it isn't doing work for someone else.
nateberkopec 9y ago
I cited decades of human-computer interaction research that disagrees with you. EDIT: also, that paragraph is purely discussing the response times for producing the HTML document of a web application, not, say if you added 100ms lag to every JS response (which would compound, like you say).
- zokier 9y ago
  I think one of the main datapoints is the classic quote from Amazon that 100ms of added latency reduces sales by 1%. There are similar comments floating around from other big players (Google etc) too. edit: this is the best link I could find for now: http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it http://highscalability.com/latency-everywhere-and-it-costs-y...

alberth 9y ago

I realize many will say Ruby is fast enough. But if you're a web developer, why WOULDNT you just develop your next net new project in Phoenix/Erlang instead of Rails/Ruby? Phoenix has most of the development bedofits of Rails, yet way better performance and scalability. Seems like a win-win. You get a Rails like development environment without any downside of perf.

sergiotapia 9y ago
I've dropped Rails for new projects and I'm using Elixir/Phoenix exclusively now. Too many benefits to list out here, but probably my favorite feature is Elixir's pattern matching. Also running my test suite in 1.4 seconds always makes me smile.
Daishiman 9y ago
Because Phoenix's library ecosystem is probably 3% of the size of Rails'.
- weatherlight 9y ago
  you also have 30 years of erlang libraries... OTP is the reason why you'd switch to elixir/otp
  - Daishiman 9y ago
    The number of Erlang users is a very, very small percentage of Rails users. OTP is great, but wiring up API connectors and auth systems and serializers and whatnot still takes up time.
deleted 9y ago
[deleted]
goseeastarwar 9y ago
You answered your own question. There’s no need to switch, because ruby is fast enough (and requires no additional training to continue using it).

pmontra 9y ago

> Languages aren’t dying based on their concurrency or performance features alone. I'm afraid this is going to be more and more about which languages run on serverless platforms. Those companies decide which languages win. Example: AWS Lambda is still Nodejs, Python and Java. We can hack about any language into it (I did with mruby), if we make Python or Nodejs exec it, but it's not worth the effort.

jaequery 9y ago

i dont know why people fail to understand. most of the slowness is not the language but the code. for instance, raw php is really fast but apps like magento and wordpress slows it down to a crawl, more slower than a typical rails app. depends per project but usually the slowness comes mostly from the abstraction with the db layer. where this means the latency to the db needs to be factored in to the benchmarks as well as to see if there are any lighter ORMs that can be used.

tomc1985 9y ago

Watch as the language and framework vultures descend on this thread...

flavio81 9y ago
no, i'm waiting for the vultures that think that every language and every platform is equal.

avitzurel 9y ago

I want to add my POV here because I've been working with Rails for 6 years and recently changed jobs and moved to Python and Node.JS (and been working with Golang for the last 3 years). One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR. The way you can start a project in a second is amazing, the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else. Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. From Authentication to Authorization and all the community around these. Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. Most of the slowness you are experiencing in Rails and Ruby apps is by doing poor engineering, not by Rails or Ruby itself. Big Surprise... If you query 1000 rows and bind them to the controller things will be slow. There are things that are natively slower, JSON parsing and marshaling for example is one. It's much slower than Go for example but it's so much easier and for 99% of us, this is what matters. I don't get the hate that Ruby and Rails are getting. Really don't.

avitzurel 9y ago
I said it before in my streams many times [1] This is a classic case of weighing solutions against other solutions. When you do that the one with the most features or the fastest will always seem the best. But, you need to weigh the solutions against your problem. Your problem is time-to-market. Your problem is development time. Your problem is software reliability. Your problem is finding great engineers to do great work. When that's your problem. Ruby and Rails are great solutions. Not good. Great solutions. Show me an express app that is as monolithic as some Rails apps and I will show you how Node.js halts to a crawl. [1] https://twitch.tv/kensodev https://twitch.tv/kensodev EDIT: Typo
- avitzurel 9y ago
  Yes. It's easier to find people with Javascript experience to work on your Node.JS app. But are they as good as the engineer doing Ruby for 6 years? Are they as good as someone doing Python for the last 10 years? I am not going to try and answer these, it will be idiotic but all of these articles and some of the thrust behind leaving Ruby and these articles are just driven by the wrong reasons.

flavio81 9y ago

Website says "The majority of web applications handle far less than 1000 requests per second." The benchmark provided (TechEmpower Benchmark) measure the amount of requests served, but these requests are for rather easy tasks like fetching data from a SQL database and serving it. Or doing JSON serialization. Drop in a more alghoritmically-complex and/or general-purpose task (say, compress this file using GZIP before saving it on your server), and then you will feel the speed (or slowness) of your platform. And here perhaps you couln't hit the magical "1000 requests per second" benchmark. Objectively, Ruby implementations (on the canonical Ruby MRI implementation) are slow. Sometimes even 100x slower than C. Taking a deep look at these graphs, where 1x is C's performance under GCC: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-... Ruby MRI is typically 20x to 50x slower than C. Looking at the graph is revelaing, but in any case, for other dynamically-typed, dynamically-linked languages, here are other typical figures for comparison (from the graph, relative to C/GCC, lower numbers better). Ruby MRI* 20x to 50x Python 3 Similar to Ruby MRI Racket 6x to 12x ECMAscript (Node.js/V8) 7x to 10x Common Lisp (SBCL compiler) 2x to 5x For statically-typed languages: Haskell (GHC) 2x to 9x Java (latest official JVM) 1.5x to 3x Swift and Go similar to Java C# (under .NET Core latest) similar to Java Rust <1x to 2x C++ (g++ compiler) equal to slightly slower than C C under GCC 1x * JRuby, as the graph can show, doesn't help too much, and sometimes can be 2x to 7x slower than Ruby MRI! http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=jruby http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... At the end, for Ruby I would take the similar stance I would take with Python --- if I use it, it's because I like it. For example, I like using Python better than Js(under Node.js). However if i was building a system that will demand performance, i'd look to other languages/implementations.

RangerScience 9y ago
Fun fact: MRI is actually designed more around memory efficiency than speed, because it's major funders are Japanese automobile companies, and Heroku; who (apparently?) care more (sometimes way more) about memory. It's also (apparently) why MRI has such a fast startup time compared to similar languages and other Ruby implementations.

mnm1 9y ago

The article isn't compelling. I'd argue most scripting languages, including Ruby are too slow for many situations. The author is thinking of one request. What if I have multiple Ruby APIs to hit? 100ms for each one adds up quickly. The frontend being a mess of many megabytes and taking 15 seconds to load is also not an excuse to make the backend shitty. Fix the front end, then the backend speed will matter. Yes, there are other considerations, but these days there are plenty of languages to choose from for the back end that offer memory management and instant reloading of code like Ruby and other scripting languages while being quite a few times faster. They also offer a chance to escape with a decent app in case the company you're working for hired a bunch of idiot architects that put in database wrapper code that takes 10x as long as the database itself to run and you don't have time or resources to rewrite the last four years worth of work in a faster language with a proper architecture. I personally cannot see choosing Ruby or any similar language (PHP, Python, JS) in the future for webdev stuff.

schneems 9y ago
> What if I have multiple Ruby APIs to hit? Then hit them with multiple concurrent threads and move on.
- flavio81 9y ago
  ... do you think available memory and CPU time do not decrease when you spawn more threads?
  - schneems 9y ago
    Use threads. They exist. Use em'. Know what threads are really good at? Hiding IO time. They're like REALLY good at it. When a thread is blocked on IO, it's not spinning your CPU. So is the thread "free"? No. Is it pretty cheap compared to re-writing an app in another lang? Yes.
- mnm1 9y ago
  And if I need to hit them in serial?

claudiug 9y ago

ruby is not slow compare with some other languages(python, js, php) but there are some other languages there, with better PR, and better ecosystem: - kotlin - netcore - swift - go All of them have a rails framework clone :) ruby needs, JIT, concurrency, and some crystal magic

tracker1 9y ago

There are more issues than just raw performance, or only raw performance. Right now, I'm working for a web services company where the vast majority of our work is via an API with a limited range of request types. We have external(locally cached) and internal data sources that all have to be queried, and dealt with before the logic can work and a response can be returned. We're currently niggling over a few ms here, and a few there. Balancing the cost of adding more servers to distribute load. Migrating from colocation to cloud hosting in order to scale more seamlessly (iirc, over 150% growth yearly or more). Our SQL database has been a big bottleneck, moving heavy loads out of SQL and into more appropriate separate data stores. Just because it's only an extra 100ms, doesn't mean it doesn't matter, as it's not the only link in the chain. I would never, for example use rails for an API service... it's too expensive on top of everything else. Right now we have a fair amount of C#, a bit of Node, and may consider some go for future use in pieces. It comes down to picking the right things... It also depends on what/where you're using the technology.

deleted 9y ago

[deleted]

throwaway47861 9y ago

The article tries a little too hard to defend Rails. It has very legitimate scaling issues and they are well-documented. The author is also way too pessimistic about newer stacks and is demonstrating a grumpy-old-fart-like attitude saying that "new stacks will find new ways to jam CPUs or I/O stacks". Might be true, might be not. It's not a fact. I also get a vibe that the author exaggerates the problems with newer stacks. And it contains way too much assumptions in the case you switch stacks. So he says that if you migrate to Phoenix or Node.JS, then: (1) The load on the DB will not change. True, but Elixir has a cache directly inside the VM so the I/O costs for a _separate_ memcached server are almost fully eliminated right from the get go. (EDIT: in my not-so-big Elixir/Phoenix experience so far, Ecto is still faster than ActiveRecord; but I do still admit the DB load is pretty much the same.) (2) 20k RPM doesn't mandate 50 engineers. I've been in a team managing an app with a 12k RPM with only two senior devs. We were just fine for the 2 years I've been there. (3) New stacks slows down development. If you don't hire juniors, this is only true for the first 2-4 weeks. I've been fully onboarded in an umbrella Elixir app containing Phoenix and GraphQL endpoints, and a total of 6 apps, for 3 weeks. I surpassed my Rails development speed for 3 weeks. Very, very bogus assumption here. Assuming that switching a stack means you do cargo-cult engineering is disrespectful. Sure he might have seen it 200 times, doesn't mean the whole world does it. As much as I love Elixir, I was honest with myself and had to write a few small microservices in Go, and I am glad that I did because it was a perfect fit. I have a huge respect for Nate Berkopec and was following him closely for a while. He's a really awesome engineer. But that essay left me with a bitter taste of "my constultancy might be endangered, time to badmouth the new stacks". Why do I think so? Again, too many negative assumptions about the new stacks. No real argument, just negativity. Does Phoenix pose its own WTF moments when you migrate from Rails (or any other framework)? Sure! It absolutely does. No tech stack is perfect. The end result however is increased developer productivity -- speaking about myself and apparently thousands more out there on the internet who claim the same -- and less server costs. And these both were measured over time. If you want to use Rails, do so -- it is the perfect choice for a plethora of projects. But there is no need to badmouth alternatives especially if you don't have a case and your entire argument is comprised of negative assumptions about those alternatives. I am disappointed with the author.

passer-by-123 9y ago

The push to new technologies are not based solely on performance. Rust brings a type-safe and memory-safe guarantees. Elixir brings concurrency and functional concepts that lead to clearer code. Even node.js has the benefit of ubiquity. Even if you want to debate those claims, those are perceived reasons for people adopting those platforms - just ask them. Having a more scalable and performant platform is just a nice bonus. It is also misleading to think that performance impacts only the user experience. No, it drastically affects the developer experience too! Over the years the Ruby community has struggled with performance issues. Your application takes a long time to boot? Let's introduce a tool like Spring that works only half of the time. Your application cannot handle blocking requests? Let's push our whole design towards jobs. View rendering is slow? Let's add cache layers over cache layers (aka russian doll caching) and then good luck debugging cache expiration issues. Even running tests is unnecessarily slow in Rails. When one test is querying the database, another test should be running. I am not talking about multi-core concurrency, just simple IO-based concurrency. Extra points if a language can give me CPU concurrency too! Those are long term issues that impact the developer productivity and increase the maintenance burden on your teams. That's without taking into account other issues prominent in the Rails community, such as abusive use of monkey patching and global state. I moved away from Rails not because I wanted performance but because I wanted simplicity and long-term productivity.