I could be mistaken, but I believe these sites are normally “using rails” (as in they shell out to other languages, Go has become common, for performance critical end points or portions of those end points that need to work a bit harder). I also suspect they’ve got some pretty heavy modifications.

I can’t speak to what they’re doing internally, but I would agree this is a safe assumption. I think the point though is that Rails, with some help of external services depending on use case, can certainly be scaled out to a level that is far above the average web service making it more than capable of handling 95% of use cases you could throw at it. In the case of Shopify, they’ve traditionally been great about contributing optimizations back to Rails so their performance optimizations are shared with the larger ecosystem (and has the benefit of keeping them closer to upstream).

The Ruby language itself has fibers, but last I knew Rails was not making use of fibers for ActiveRecord. The problem is effectively you’re in an interpreted language (bad enough) without real parallelism (worse). So, when any IO occurs one of your non-parallel threads is blocked.

To your point, Ruby recently introduced Ractors which are true parallelism. They’re new enough that their use isn’t widespread yet, but I’ve played around with them and it’s definitely neat to have real parallelism in Ruby now. And for web services, this would depend too on the web server. For example, using Puma or Unicorn will have multiple worker processes so there is some parallelism between requests regardless.

The problem you run into here is a lack of mature libraries to leverage if you want to do anything non-trivial. e.g., our application needed to read from spreadsheets. The Ruby libraries either A) didn’t have support for common formats like xls or B) would load the entire spread sheet into memory represented as Ruby objects (you can predict how well that performed :) ).

Yeah, I get that. For what it’s worth, I really can’t think of a situation where there hasn’t been some library written in Ruby for something that I needed shy of extremely esoteric stuff that I likely would have needed to write myself if working in another language anyway. But that’s going to be highly dependent on a case-by-case basis. For what it’s worth, I make it a point to use as few third-party libraries as I can unless they’re highly popular. It’s a problem in all languages that random person’s pet project library, while highly useful, becomes abandonware far too often.

I think we eventually started using something akin to that. However, I’m a big advocate for making the wrong thing look wrong/complicated, and Rails very often makes the wrong thing look simple. Note that gems like this don’t really solve the problem they just inform you when you’ve made the mistake, or alternatively forcing your app into hammering your database even in situations when it doesn’t need to

You might be referring to the Bullet gem which is just a notification that there’s an N+1 and where to find it so it may be fixed. However, the JIT Preloader gem actually does automatically solve the problem of N+1s in nearly all cases (see the README for details if you’re curious). It’s the closest to a silver bullet solution for the N+1 problem as I’ve seen and I now give almost zero thought to N+1s anymore. I know the devs were wanting to get it merged into Rails to solve this problem for everyone, but I don’t know what happened to that effort.

I agree, but there is something to be said for hiring people that are extremely knowledgeable in the framework to help highlight solutions (like those you’ve mentioned here) vs “you’re a great C++ dev, now go do Ruby!”

Right, I wouldn’t portend that anyone can make an easy switch from, say, embedded systems to web development in a few weeks or even a few months. I meant more like if you’re competent web developer the core concepts of building web backends/frontends don’t vary all that much between frameworks. At the end of the day, the underlying concepts deal with HTTP and HTML/JS/CSS so if you have a solid understanding of the base concepts and system design for the backend it shouldn’t be much trouble to switch the framework sitting on top of those, especially if you have a team around you that is effective at code reviews, answering questions, and generally investing in new employees. Like you said, switching from something totally unrelated is a different situation though.

Thanks for a thoughtful reply, by the way. :) I really shy away from getting into pointless internet fanboy debates over which tool/language/framework is “best” but always enjoy when there’s thought out reasoning behind points.