Hacker News new | comments | show | ask | jobs | submit login
Is Ruby Too Slow for Web-Scale? (speedshop.co)
84 points by nateberkopec on July 11, 2017 | hide | past | web | favorite | 94 comments

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.

In chronological order of professional web experience, I used PHP for 3 three years, Python for 6 years, and am about a year into Ruby. I've got tons of time in other languages and areas as well, but that's less relevant to this discussion.

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

So far I find Rails very sane and well-thought-out, but I really, really dislike Ruby. I realize that's a personal preference issue, but it is what it is.

> The way you can start a project in a second is amazing

This seems pretty ubiquitous to me with "batteries included" frameworks. Rails doesn't have a huge leg up here over, say, CodeIgniter circa 2009.

> the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else.

I very much like Rspec. One of Ruby's greatest strengths is the ability to define simple and semantically meaningful DSLs. Rspec is a great example of a good DSL.

> Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't.

I agree 100%. Python is my preference, and not because it's lightning fast. It's fast enough that I'm almost never trying to improve performance, and when I am, my project has progressed to the point that it makes sense to scale horizontally instead of trying to make it fit into existing resource constraints.

> I don't get the hate that Ruby and Rails are getting. Really don't.

For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out.

> For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out.

I hear this almost every time Ruby is discussed, but I've been building rails apps pretty much exclusively since 2007 and I've only once experienced this problem and it was due to someone trying to make the most generic thing possible to solve a relatively simple problem incorrectly.

Can you point to a specific example? Is it in Ruby libraries? Is it in the application code you are working on? In Rails?

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

EDIT: Typo

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.

That's a fair question... I've been building web based applications for over two decades now... I've been a fan of JS since before the "Good Parts" book, though that spelled out a lot of what I already knew. There are a LOT of developers that use and know a little about JS.

However, the vast majority of "JavaScript Developers" don't know JavaScript all that well. Most haven't taken time to learn the newer features and/or syntax. Many try to write JavaScript like it's Jave or C#, or whatever else instead of using it for its' strengths. Not to mention performance implications.

Most of the time a lot of that doesn't matter. Most apps have enough performance to handle their load, and if they can scale to 4-5x the users with minimal relative extra cost, it never will. But when you do need those extra bits, it helps a lot.

I've worked on a few node/c# apps where each ms counts... getting an extra 10k requests/second on a large server, or reducing latency by 10ms is a win. Not all things are equal. One should evaluate each use case.

To each their own... I only dabbled in RoR and wasn't much into it. Ruby seems like a great next gen Perl imho, and I thought that was cool. I just didn't like the everything in the box RoR experience. I lived through the early ASP.Net and didn't want a repeat of that. I like the lego blocks approach that Node and .Net Core are taking. I try to avoid many of the bigger pieces/sets.

I'm really interested in the answers to those questions, because I have experience working in Python and JS shops and I haven't noticed much of a difference in terms of engineering quality between the groups. I suspect it's because most JS and Python engineers lack experience working with "non-magical" languages, and thus they frequently lack the ability to make good performance estimates or balance competing priorities. Or maybe the non-magical thing is a red herring, and it just happens that non-magical languages tend to be employed in domains where "just make it work; we'll solve performance with hardware" isn't acceptable.

This isn't to hate on Python or JS engineers; just that I don't see the same jump from JS to Python/Ruby that I see in dynamic to static languages (esp static langs with manual memory management).

>Big Surprise... If you query 1000 rows and bind them to the controller things will be slow.

Every time I've been involved in a situation where people complained about Rails being slow, this was the problem. It's not the ORM's fault if you're pulling every row from a table and iterating over them to find the record you want. It's not the framework's fault if you're pulling every row from a table to calculate the average value of a column. And it's not the language's fault if you're pulling every model entry into memory and chopping the array by hand to power pagination.

Rails doesn't save you from having to know SQL. No ORM can do that. The best an ORM can do is save you from having to actually write SQL most of the time.

After 18 years of programming in a wide range of languages (almost 10 spent on Ruby/Rails) I surely agree that Ruby is a joy to use for many tasks. A different opinion goes to Rails: it's speed of development is inversely proportionate to the time taken to reach a messy codebase if you follow the infamous rails way. You need some decent design pattern to get something that is still usable after 6-12months of active development. Performances and speed can be important for many aspects, especially when there are alternatives that offer same speed of development consuming 10% of the resources needed by a ruby/rails app. Can you put a non trivial web app written in rails on a 512mb ram/1 core VPS for production (serving responses in microseconds, and consuming only a total of 50-60mb of ram)? That's what I did with 2 apps written in Elixir/Phoenix. The speed of development was the same (if not better!) than Ruby/Rails, the apps are running on cheap instances and can be scaled if needed. The hate toward rails: it's getting more crappy on each release. Several new additions (especially in the v5.x) are pretty wrong (eg: global shared variables). Yes, it's still a choice, but it has lost the real game-changing that was few years ago.

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

You should compare Express to Sinatra, not to Rails.

Express is ridiculously easy to learn, btw. Coming from Flask (under Python), i learnt Express in 3 hours. Seriously.

> Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't.

Speed DOES (caps, emphasis) matters for many projects, in particular the projects that will go to real-life, to get massive use by consumers/common people. However, I do agree that for prototyping, startups, or simple apps that don't demand lots of performance, the speed of development under Ruby and its tools is a very important asset.

> I don't get the hate that Ruby and Rails are getting. Really don't.

Agree with you, one shouldn't "hate" Ruby, no reason, really.

The express <> Rails comparison was not meant to be a feature to feature one. I did not explain myself correctly.

The point on the speed for me wasn't that speed as a whole doesn't matter. Speed in the language level doesn't matter.

If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds. It simply doesn't matter all that much in the language/framework level for most of us.

For example: In my current job place we are using Flask for all microservices. One of the endpoints was very slow to respond and took 3 seconds. It ended up being a missing index in the DB.

Once fixed it's taking 20ms.

So, Is python slow because it's taking 20ms vs 12ms?

> If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds.

Honestly, if you do the same stupid shit with Go, it will take 0.51 seconds, according to many benchmarks out there.

> So, Is python slow because it's taking 20ms vs 12ms?

No, bad code is bad code. But on companies that have good programmers, sometimes you do hit a performance problem caused by the platform, and then you have to either a. throw more money (more servers, more CPU cores, more mem), or b. rewrite that section in other language. Actually, for example this is what some Python libraries do, for example Numpy has a lot of code actually implemented in C, not python.

> Honestly, if you do the same stupid shit with Go, it will take 0.51 seconds, according to many benchmarks out there

The whole point is that CPU-bound web framework time is never the bottleneck for most companies. Golang doesn't change your database network latency.

If you DO hit the rare cpu bottleneck, you can offload it to services, cffi, whatever. It's so astonishingly rare that it doesn't make sense to optimize for most of the time.

> I don't get the hate that Ruby and Rails are getting. Really don't.

Is RoR really getting much hate? Because I sure haven't seen that. Admittedly I usually don't really pay that much attention to random framework flaming, so I might not be the best to judge, but I feel like at least on HN RoR is still discussed in mostly positive tone. Besides "everyone" already knows that RoR is dog-slow (relatively), which I think balances the discussion to reasonable level.

What I see is a big shift. few years back, lots of the companies I knew and worked with had a Rails based product.

Most of the companies I talk to today, don't choose Ruby. They mostly go with JS (Either express or Meteor or others).

The "Hate" for me is articles like this. Don't know if "Hate " is the right word.

Yeah, the crowds have moved on from Rails/RoR. But the crowd is also always moving with latest fad, almost by definition. That does not imply any sort of hate in my view.

I don't even know if this is a bad thing - engaged developers want to work with what's new and exciting, especially early in their careers. Using a "fresh" stack is a means of targeting those devs and wooing them to your company.

I also believe there is a very viable long-term strategy of choosing a few of the current "hotness" stacks over your early career and learning them thoroughly. When the time comes that you're not wanting to chase the new thing so much and you start to experience age-related discrimination, you can focus on maintaining and improving existing projects written in those "old" stacks. There are lots of people out there today making good money doing "unsexy" work like maintaining Java/JSP or ASP Classic apps. In ten or twenty years, those jobs will be maintaining Rails, Django, and Laravel apps.

It is not bad thing, it is just how things are, and I suppose it drives progress in the long term. Younger generations picking up slightly different sets of tools, with different tradeoffs and features. This relatively chaotic movement turns into evolution as some of the ideas stick and get reinforced, and that evolution hopefully will create progress. Of course all this takes long time and in the meanwhile we might see both major misteps, and moments of brillance that nevertheless for some random reason get forgotten and buried.

It's a bit silly to compare Express to Rails, Express is the Sinatra of JS, and the Sinatra philosophy is to be minimalist and give you more power, whereas the Rails philosophy is to be everything you need assuming you have typical requirements. It's a trade-off, neither is inherently better or worse, they're each good for certain situations.

Maybe I wasn't clear enough.

I am not comparing Express to Rails feature to feature (which if you read my other comments you understand I am against).

Anyway, welcome to HN!

It is great that as your first comment you say someone else's comment is silly.

I'm sorry. I didn't mean to come off snippy and I must have read your comment wrong. It's been a long day.

You talked about how great Rails is but you also switched to Python. Why the switch?

New workplace is a python shop.

All of our microservices are written in python and gateway to services are written in Node.JS.

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

If you're talking about humans, absolute time is much more important than "3X". Everybody would notice the difference between 1 second and 3 seconds. Nobody would notice the difference between 1 ms and 3 ms. 100ms is perceivable, but not a problem in most situations involving a web request.

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.

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

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


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.

"web-scale" is a fairly established term (overused sure, but established). Arguing that most sites are not web-scale is beside the point.

As someone who's spent a lot of time scaling up ruby servers (I like to think I know what I'm doing), I can say it's not ideal for any high-scale applications for a few reasons:

1) It's hard to scale: Just look the thousands of stackflow posts on MRI garage collection tuning, unicorn forking, puma clusters and RoR performance to see that people struggle with it long before any huge scale. Other languages/frameworks are often 30x faster out of the box and cause fewer headaches when scaling up (we've been using GoLang lately). Ruby is easier to write and I love it for that, but much harder to scale. It takes more effort in the long run for high-scale apps.

2) The community tends to design for smaller scales. The ruby community is awesome, but as a result of focusing on lower traffic apps and single threaded/process web servers, a lot of the gems aren't designed for high throughput or concurrency. For example, ActiveRecord's connection pooling is often painful. Also, I found a pretty critical concurrency issue in the very popular DelayedJobs gem a few years back which had gone unnoticed for years.

3) MRI has performance issues: the GIL, slow GC, slow threading and other issues make it a slow language. It's fine for a lot of use cases, but try serving images, video or doing a lot of processing and you'll quickly hit its limits.

You absolutely can make Ruby work at huge scale, but it's much harder. I wouldn't recommend it if you hope/plan to require high-scale.

1) All it really changes is the ratio of application servers to DB servers. If you're running $40k of servers a month it might be worth it. Otherwise, probably not. At the time Twitter was struggling with scale they were also still running on a single MySQL server.

2) Rails has been thread safe since 2008. Ruby/Unicorn was serving some of the busiest sites on the internet in 2010. Go only went stable in 2012.

Connection pooling in other frameworks is usually even worse. Rails is the worst web framework, except for everything else.

delayed_job wasn't designed to be high throughput or threadsafe, but Resqueue and then Sidekiq certainly were.

3) The GIL also massively simplifies the Ruby internals for the core dev. Some platforms don't have performant hardware mutexes. Even dealing with OSX, Linux, Windows and *BSD is a nightmare.

The GC is actually really fast in Ruby 2.1+

Images shouldn't be served directly through Rails, even if dynamically generated. You're asking for a world of pain doing that.

I previously worked on a high-traffic mapping application where we generated the map tiles on the fly through a Rails app and served the images directly and we no scaling issues caused by Ruby/Rails but we did have plenty of CPU load from Imagemagick!

1) That ratio can be 40:1+ for a lot of use cases. That adds up in costs and if you have any other limitations (DB connections) it can be a total deal breaker.

2) I said many gems, not Rails. Connection pooling in other frameworks is worlds better (GoLang's db package comes to mind). We're talking about now, not 2012.

3) Sure GIL is convenient when thinking about code, but the point is it makes high-scale hard. 2.1 GC is only fast by ruby standards. "Images shouldn't be served through rails" < exactly my point, other languages handle this with ease. If you are building a high-scale app you can choose 1 language+framework, or RoR AND another when things are big/hard/tough.

IMO, RoR (and Ruby in general) makes easy things easier, but hard things harder. A good tradeoff for some projects, but not big or high-scale ones.

1) I honestly have not seen a ratio that high for a web service. Most of the hot points of serving a web request through Ruby are actually written in C, so on the same machine I can only serve about 2x as many simple JSON requests through Gin as Sinatra. Once you add in waiting on IO for a DB call this gap gets narrower until it basically disappears.

What blows it out to 40x? Some sort of live image/sound manipulation?

If it was an inherent problem with Ruby, you wouldn't see such fantastic performance from nginx_mruby.

2) Sure, the Go connection pool is nice, but the Go ORMs are horrible as they try and work around the warts of the language. Everything's a trade-off, really. You give up terseness and flexibility for performance.

3) The GIL is definitely not convenient when thinking about code. Threads in Ruby still require you to write thread safe code. The GIL exists to make the _Ruby VM_ simpler. Otherwise you end up in the situation of Lua, where you have to re-initialize the VM in every thread and essentially have sub-interpreters, or you build something incredibly complex like the JVM.

The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend.

Images shouldn't be served through a dynamic web app regardless of your language. They should be served directly via a web server to a cache/CDN, even if you're generating them on the fly like dynamically composed map tiles. People pan away. They pan back. You don't want to regenerate the tile.

>The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend.

I have read this number of times, now one Method JIT is shown, what is the other one?

+1 Best post on the whole thread.

Did you read the article past the benchmark numbers? That's more-or-less exactly the point the author made by the end. To wit:

> The majority of web applications handle far less than 1000 requests per second. I’d go as far as to say that most web application developers are employed by a company whose entire webapp does far less than 1000 requests/second. Most of them do less than 1000 requests/minute.

> When your application is big enough to be doing 20,000 RPM, you will have anywhere from a half-dozen to even fifty engineers, depending on your application’s domain. A single software engineer costs a company at least $10,000/month in employee benefits and salary. So we’re choosing our frameworks based on saving one-third of an engineer per month? And if that framework caused your development cycles to slow down by even one third of a mythical man-month, you’ve increased your costs, not decreased them. Choosing a web framework based on server costs is clearly a sucker’s game.

> What does web-scale even mean? It's an old-ish meme, from this video making fun of MongoDB. [1]

1: https://www.youtube.com/watch?v=b2F-DItXtZs

The majority of web applications handle far less than 1000 requests per second.

To be fair, two points:

a. The benchmarks do rather easy stuff like fetching rows from SQL and then serving them. No heavier stuff (like compressing a file, etc).

b. On the provided benchmark, Ruby on Rails with Unicorn barely achieves 2000 request/sec.

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.

> I've heard places convert from a Ruby stack to Java


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!

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

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.

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.

> But who's realistically writing webapps using Ruby without Rails?

Sinatra is very popular...

Which alternatives do you recommend?

Leverage your Rails knowledge and jump onto greener pastures with Elixir/Phoenix.

It's faster than Python, at least by my most recent personal benchmarks.

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.

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.

Because Phoenix's library ecosystem is probably 3% of the size of Rails'.

you also have 30 years of erlang libraries... OTP is the reason why you'd switch to elixir/otp

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.

Because you don't "just" develop your next project in some other language/framework. You and your team have to throw out domain knowledge and make a whole bunch of mistakes with the new language/framework before reaching the competency you "just" threw away.

"Just" is a terrible word we use far too frequently in the software industry.

A really huge reason stands out above the rest and is relevant for development shops and tech teams alike: you already have an investment in your tech stack (team, existing code, training, etc). This has knock-on effects as well - teams can move between code bases easily, there's a single idiomatic way to do things, common code quality standards, and much more. This isn't a sunk cost either, if <x tech> can get the job done and "more performance / scalability" aren't requirements, then there is tremendous cost to choosing a new pet tech.

Multiply "learn new language X and new framework Y and new idiomatic ways of doing things for Z" by the number of developers you work with. It's not a win-win and deserves consideration.

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

Need? No.

Compelling and valid temptation? Yes.

Productivity. Functional programming is like ancient Latin to many programmers. The pool of people with prior experience that you can hire from is smaller and the learning curve for a new hire is going to be greater.

But the ones who learn, will become better programmers. Functional programming has already been proven out in the field, since the late '60s. In fact, there is a recent trend to more use of functional programming, just as in the 90s, OOP was all the rage.

What is hard, is to use a purely functional language.

I wrote https://affluentconfidante.com/ (which may or may not have been commissioned by a wealthy client who wants to deliver an anonymous message to the world) in Clojure and deployed entirely on AWS infrastructure.

By design it is simple, because in my experience, the biggest obstacle to scaling properly is over-engineered code, especially premature optimizations that have the wrong guesses about what will need to scale.

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.

> What if I have multiple Ruby APIs to hit?

Then hit them with multiple concurrent threads and move on.

... do you think available memory and CPU time do not decrease when you spawn more threads?

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.

And if I need to hit them in serial?

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.

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.

This is something I think Django got much more right than Rails - it encourages splitting up of "sites" into smaller "apps", where an app is a bundled set of model/view/controller/routing and maybe a few other things. We exercise this design pattern a lot on the project I work on (we have ~350 apps in our monolith) and it's mostly a very nice codebase to work on.

I think microservices become far less necessary when the monolith is structured in this way. I'd rather have a clean API to a subsystem exposed as a Python function call than as an HTTP endpoint with all the reliability and distributed systems issues that come along with that.

This is also called "package by feature, not layer" in Java.

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.

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

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.

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



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

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.

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.

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.

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.

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

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.

Interesting. I don't know how I missed that page. I'll update my statements and opinions (and slides)....

...but Twitch still uses Ruby[1], and was still originally in Rails. It still stands as an example of scaling Rails, even if it no longer uses it.

[1] https://jobs.lever.co/twitch/c795ef2d-2621-4383-8aa1-c85c875...

Zendesk is slow as hell

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.

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

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:


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!


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.

>> where 1x is C's performance under GCC <<

No, 1x is NOT C's performance under GCC.

As-it-says - "the fastest written in any of the programming languages" - and currently those fastest programs are written in C, C++, Chapel, Fortran, Rust.

You've been led astray by the benchmarks. The reality is it's literally as fast as C because you're just hooking out to zlib.

It's much better to think of Ruby as a Smalltalk like high level language used to glue together lower level high performance building blocks.

Looking at things from this angle we see the typical Rails arrangement is actually business logic written in a high level language calling a bunch of native libraries eg. application server (Unicorn), HTTP parsing (Raygel parser), JSON parsing/generation (oj), HTML parsing/generation (nokogiri), DB client (pg).

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.

Yes, but take a look at the memory usage benchmarks (on the cited benchmarks) and Ruby is similar to Java's JVM on memory usage, sometimes better, sometimes worse.

You would need to compare "toy program" by "toy program", but for example, for the regex-redux program:


Bottom line is... MRI runtime is as memory hungry as a Java JVM runtime.

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

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

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

Is web scale like the internet tax?

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

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact