[rockyj]

I do not agree. Rails is absolutely great in terms of features and productivity, but will fail you elsewhere i.e. it is not the silver bullet for webdev. Do not take my opinion, look at data - https://www.youtube.com/watch?v=Qp9SOOtgmS4

If you are using Rails for anything where you are not absolutely sure of how many users or RPS you will have, you are just saving money in launch time but spending more on servers.

[BoumTAC]

Shopify is built using Ruby on Rails, they successfully handle enormous traffic spikes during Black Friday sales without issues.

So I think we're good with performance.

[rockyj]

Everything can scale if you throw enough servers at it. Of-course Shopify scales, they even spent time and money to build a JIT on top of Ruby. As a smaller company, does everyone have the time and money to spend on servers or optimising the language to this extent?

[bnferguson]

That's the nice thing! You don't need to optimise the language and build a JIT as a smaller company, Shopify already did that for you. Just like Google did for Javascript, which lead to Javascript having any performance at all (which lead to node being a thing).

Also remember that Shopify didn't start out making billions. They started as a small side project on a far, far slower version of Ruby and Rails.

Same with GitHub, same with many others that are either still on Rails or started there.

You can optimise things later once you actually have customers, know the shape of your problem and where the actual pain points are/what needs to be scaled.

To me, I care a ton about performance (it's an area I work in), but there's not a lot of sense in sacrificing development agility for request speed on things that may not matter or be things people will pay for. Especially when you're small.

[chucke]

No, they only have time for features and productivity, which is, as you pointed out earlier, what rails is good at.

[lentil]

Smaller companies have less traffic, need less expensive servers, and have no need to spend money optimising the language. They can focus on that when they make billions of dollars, like Shopify does.

[axelthegerman]

And in the meantime just passively benefit from the OSS improvements along the way

[ksec]

>So I think we're good with performance.

>On Rails, the most heavy page has a P95 duration of 338 ms. There is of course room for improvement but it's plenty snappy.

I guess everyone will have different opinion on P95 at 338ms. The great thing is that we are getting cheaper CPU Core price and YJIT. As long as this trend continues, the definition of Fast Enough will cover more grounds for more people.

[dajonker]

There's lots of tricks you can do, such as preloading pages when the users hovers over the link. This makes even a "slow" page load of 400ms feel pretty much instant to a human.

[dajonker]

These kinds of tests are useless (to me at least) for three reasons.

First, these kinds of tests don't do anything useful and just show that some frameworks have more overhead than others. Once you have an app that was developed over years rather than hours and actually does a lot of stuff on every request, it's a whole different game.

Second, the kinds of applications I write rarely get more than 10-20 requests per second. If Rails would peak at 2500 rps as that YouTube video tests it at, that would be plenty. If I were writing some kind of IoT platform rather than a business app, I'd probably not start with Rails for that reason.

Third, for an actual web application, you want to consider what the user experiences, not just how fast the server responds. You can make an application feel much faster than the server response times by preloading on hover, (http) caching, async loading of things that are not visible yet, etc.

[CPLX]

> just saving money in launch time but spending more on servers

That seems like an amazingly good trade off, even if it were true which I am not sure about.

[graypegg]

I'd go as far as saying it's a selling point, not just a compromise. Flexibility now can come at the cost of vertical scaling when it's EASIER to get funding and when you will probably have cash flow? Hell yeah. Compared to preemptively hyperscaling at an initial high cost, or using a possibly non-existent mythical framework that is somehow hyper performant, low cost, and as flexible as Rails etc... I know what I'd go with.

[timeon]

It is. On the other hand this kind of mindset is the reason why there is climate change.

[CPLX]

I’m pretty sure the decision to use Ruby On Rails instead of another platform for building my web applications is not in fact the reason why there is climate change.

[wutwutwat]

the "rails doesn't scale" myth has been debunked for a decade now and anyone with the slightest clue about performance can scale a rails app using the same techniques that you'd use to scale any other language and framework

yjit and fibers have made things even better, and plenty more is coming I'm sure

[biorach]

> you are just saving money in launch time but spending more on servers.

But... That's kind of the whole point

[hit8run]

If RPS become a problem you can probably switch to JRuby. I did exactly this 15 years ago for EUs biggest software company and it worked out quite well.

[rockyj]

Have you seen the latest state of JRuby development or seen the posts of its development team. If you are comfortable with the idea of your main runtime being dependent on the time / finances / availability of around 5 (or less) core developers I would say you are ok with JRuby.