[nickjj]

> they could have probably build a very Ruby on Rails like framework on a language more suited to the size and scale of these platforms.

I have a hunch they would rather have tens of thousands of other folks using a framework that has massive community support and folks other than them directly maintaining it.

Also being able to Google almost any problem in Rails and find multiple really good answers is worth needing 5 or 10 times more compute costs on just your application servers because dev time is expensive at any scale.

If you're paying 2,000 developers 150k+ a year that's 300 million dollars without accounting for anything that scales off base salary (bonuses, 401k matching, etc.). If you can save each developer 5 hours a week because of the Rails community existing that's 10,000 dev hours a week saved. An average person might work let's say 1,900 hours a year. That's roughly ~5.2 years of dev time saved from using Rails in opportunity costs and direct costs per week. Direct costs alone is ~$790k per week. I don't know what Shopify or a bigger place is paying on just application server costs but I'm guessing it's well worth hosting Rails instead of building their own framework in a more computationally efficient framework.

I think these numbers are really generous too. I'm guessing using Rails is saving a lot more than 5 hours a week of dev time per developer.

[pdimitar]

I keep hearing that argument my entire career... and I've attended at least 7 instances of it being very false.

The point is, nobody is even trying to do what you also renounce -- hence there's an inherent confirmation bias in the claims of "rewrites are hard" or "in-house frameworks fail". I think we should recognize that.

There are ways to surgically and gradually migrate away from a slow technology. I've done it several times in my career and my only fail was a failure of not knowing all business requirements -- lesson learned, never made the same mistake again after.

I am pretty sure in in orgs like GitHub and Shopify the business requirements can be gathered and catalogued. It's all in there.

[dalyons]

Rule of thumb for “fully loaded” employee cost(inc benefits etc) is 2x salary. So double the cost side :)

As you say, engineering staff costs outweighs app server costs by so many multiples it’s crazy.

Now modern data eng/warehouse stacks on the other hand, those are money fires :)

[FridgeSeal]

> Now modern data eng/warehouse stacks on the other hand, those are money fires

No but I totally need a 100k+ contract (plus extra for runtime costs) to do…database stuff that…uhh, no other column based database is uhh, totally capable. Yeah. /s

Also we totally gotta buy these other data tools, because all of our “data” people refuse to learn even basic code, and can only write sprawling notebooks.

Oh plus gotta pay for some databricks/dbt to run my sprawling notebooks on huge machines because our Python based runtime is single threaded, can’t utilise the full CPU properly and requires silly amounts of memory, but it’s ok because “developer velocity” let us put an incomprehensible notebook into production a whole 15 seconds faster.

[onebot]

How much did they spend to write this compiler? Also, I would say they spend at least 5 or more hours per weak writing tests to handle all edge cases for any new code they commit due to the language being dynamic? Also, what kind of community is there for a custom compiler as well as the non-standard high performance things like using CRuby. I think it is easy to assume developer productivity is increased--and I think it is for small/medium projects. But at this scale and complexity, my assumption is that they are likely spending more development resources to support the language in their high performance environment.

[nickjj]

Having a statically typed language doesn't mean you don't write tests.

Sure, there's a subset of tests you can avoid writing but you're still going to be writing a ton of tests with both language types. I also think this point gets blown out of proportion. For example I don't write a ton of boilerplate "what if I pass X type to Y variable" types of tests in Rails because I trust the database and Rails' validations. For example if I have a datetime field in a DB which is automatically defined as a datetime in Rails I'm not going to write a separate test for what happens if I pass in a string, integer, boolean, list, hash and so on. I'd write a test around making sure the date is within a specific range if I hooked up a validation rule to it to limit the range, but I'd write the same test with a statically typed language too.

Also, Stripe has a good write up[0] on how they use Sorbet to add type checking for Ruby and how they applied it to a multi-million line code base without disrupting developers too much. Basically a small team did most of the work, including writing the tool and migrating the code base. I haven't used it personally but it exists and can be used successfully at scale.

[0]: https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby