[datadeft]

Scaling a non-scalabe by default framework that should have been few services written in a performance first language at a billion+ USD company.

I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably Rust as well nowadays).

For millions of users the CPU cost difference probably justifies the rewrite cost.

[gls2ro]

You are connecting the dots backwards, but a project is usually trying to connect the dots forward.

So if you have a lot of money then you can start implementing from scratch your own web framework in C. It will be the perfect framework for your own product and you can put 50 dev/sec/ops/* on the team to make sure both the framework and product code are written.

But some (probably most) products are started with 1-2 people trying to find product market fit or whatever name is for solving a real problem for paying users as fast as they can. And then delegate scaling for when money are going in.

This is similar because this is about a startup/product bought by Microsoft and not built inhouse.

For fast delivery of stable secure code for web apps Rails is a perfect fit. I am not saying the only one but there are not that many offering the stability and batteries included to deliver with a small team a web app that can scale to product market fit while keeping the team small.

[danmaz74]

"For millions of users the CPU cost difference probably justifies the rewrite cost." This is only true if you have expensive computations done in Ruby or Python or similar, which is very rarely the case.

[consteval]

Not true, Ruby and Python are absurdly slow at even trivial tasks. Moving stuff around in memory, which is most of what a webapp is, is expensive. Lots of branches is gonna be really expensive too.

[danmaz74]

I've got more than 15 years of Rails production experience, including a lot of performance optimisation, and in my experience the Ruby code is very rarely the bottleneck. And in those cases, you can almost always find some solution.

[ainiriand]

You really do not know what you are talking about, it is not about the language, like it was repeated in this forum many many times already. We serve an application in PHP to thousands of users per second in less than 100ms constantly.

[hamandcheese]

Sometimes it is the language. Or at least the ecosystem and libraries available.

My go-to example is graphql-ruby, which really chokes serializing complex object graphs (or did, it's been a while now since I've had to use it). It is pretty easy to consume 100s of ms purely on compute to serialize a complex graphql response.

[Lio]

I have mixed feelings about this. It's saying that python is too slow for data science ignoring that python can outsource that work to Pandas or NumPy.

For GraphQL on Rails you can avoid graphql-ruby and use Agoo[1] instead so that that work is outsourced to C. So in practice it's not a problem.

1. https://github.com/ohler55/agoo

[datadeft]

> python can outsource that work to Pandas or NumPy.

Exactly. So C/C++/Fortrant is better in this regard than Python.

[ainiriand]

I would make a case that that's not the language's fault. You need to assess how critical is speed in your requirements and adapt your solutions.

[datadeft]

> You really do not know what you are talking about

> it is not about the language

Sure how about these people?

https://thenewstack.io/which-programming-languages-use-the-l...

[neonsunset]

Yup. As if there is no wealth of organizational knowledge and a particular first-party language to address this exact problem.