[oopsthrowpass]

blasphemy, this should immediately be moved to microservices and AWS and cost optimized and each component should be scaled separately (maybe some components only need 0.5 CPU, think of the cost saving t3.micro could bring and you have a highly available 3AZ potato to make sure it never goes down!!)

Then to handle any load we need to build autoscaling and spin up the toaster to medium potato and 20 instances (this costs 60k a month, but no worries we only pay for what we use so we will only run this for 27 minutes during our big sale).

Oh what wonderful world we live in and the pain we inflict on ourselves.

GJ Shopify for running a sane (tm) tech stack :)

(btw of course Rails scales it's shared nothing setup, spin up infinite app servers as long as the db can handle it. It's pretty expensive for compute though)

[stevebmark]

Maybe you haven't worked on a large production Rails app? Rails takes 3-4x the infrastructure hosting costs as other languages/frameworks. Not to mention the insane testing costs from Ruby test bloat.

[ksec]

This could / was definitely true in the 201x. When most of the world's developers 's wages hasn't gone up evenly, and cost / infrastructure performance was expensive.

But we continue to see cost / performance improving. Ignoring the Rails framework and Ruby VM both together has likely gotten 2x speed improvement. We will get 96 Core Graviton v3 or 128 Core Zen 4 EPYC. Cost / Core performance is coming down and will continue to do so at least until Zen 6.

Depending on your App, somewhere along the line it will surely lean towards Ruby Rails's flavour. Assuming you do value what Rails have to offer.

I am just waiting for fibre/ async ( or something similar ) to be built into Rails and Active Record, along with even faster RubyJIT.

[throw3823423]

I worked at a very large Ruby shop where errors in production were very expensive. This meant that we spent many times more money on instances running the test suite for every build than we spent on all production servers combined.

[briantakita]

I got burnt out on Rails after the third app in a row that I was responsible for upgrading. I appreciate Rails' contribution to web development. It took about a decade for the front end framework-library ecosystem to figure out that MPAs are more effective than SPAs for most apps. Fortunately, Astrojs is part of the ecosystem. It's sortof like the fullstack JS version of Rails/Sinatra...without the ORM which IMO adds incidental complexity.

If you have a thriving business already using Rails, it's difficult to justify moving off of Rails...now that painful upgrades seem to be mostly in the past. However, I do find isomorphic JS components & state management to be a pleasure to develop & maintain compared developing an app in two languages.

[throwaway2990]

I had to upgrade a project from rails 4.2 to 5.0 and it took like 3 weeks because things just broke randomly.

Upgraded a .NET 4.7 project to .NET 6 in 3 days and haven’t touched it since. And the .NET project was larger.

I haven’t done rails since that upgrade and I hope i never have to touch it again.

[cjblomqvist]

Just to highlight; That's 6 major versions of .NET (so at least 7+ years in between). Including the Core era.

[cultofmetatron]

come checkout phoenix. you get a lot of the same batterries included benefits of ror but the architecture is more moduler. runtime performance is closer to go-lang and there's a really fantastic websocket and reactive frontend system built in. Erlang OTP takes it a whole other level beyond that too if you're trying to scale up.

[fredrikholm]

> runtime performance is closer to go-lang

If you squint, yes. Erlang has had NIFs and ports since forever precisely because it isn't great at CPU intensive tasks.

In most cases however, you're still looking at an order of magnitude less servers than the equivalent Rails/Django application.

[pelasaco]

If you plan the updates since the beginning, and are up-to-date with what's coming next, you are good. Having the app dualboot, running it in your CI to catch upcoming changes is a easy way to avoid such headaches

[stevebmark]

This is an ironic comment on a Shopify story, they have wasted a lot of time upgrading Rails https://shopify.engineering/upgrading-shopify-to-rails-5-0

[pelasaco]

yeah people learned with time. Github had the same problem too.https://github.blog/2018-09-28-upgrading-github-from-rails-3..... in 2023 it is so well documented, and so easy to automate, that shouldn't happen anymore.

[stevebmark]

It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.

[iforgotpassword]

Well the rest of the comment still holds. Rails doesn't get easier if you'd split it up into 200 Microservices.

[mathverse]

Infrastructure is cheap. Labor is expensive.

[stevebmark]

I agree labor is expensive, which is why you shouldn't use Rails. Shopify brags it took them only a year to upgrade Rails one major version https://shopify.engineering/upgrading-shopify-to-rails-5-0

[nithinbekal]

That's from 6 years ago. Shopify has used Rails' main branch since 2019.

https://shopify.engineering/living-on-the-edge-of-rails

[mlrtime]

Infra is cheap when you're in hyper build mode. When your growth rate stalls and your expenses are greater than your income, infra gets expensive very quick and will kill your company.

[threeseed]

a) Shopify has been deployed to the cloud since day one.

b) They run multiple app servers so each component can in fact be scaled separately.

c) They built their own PaaS which runs on Kubernetes.

d) You would have to be utterly incompetent to not care about optimising costs.

But I am glad we both agree that Shopify is doing a great job running a sane stack.

[jduff]

Just to clarify, Shopify spent about ~10 years running on metal in multiple DCs until ~2015/2016 when it moved most of the workloads to GCP.