[jupp0r]

Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.

[mosselman]

If your reverse your comment you could say “only when your reach 100s of developers will you need to start changing things a bit.”

Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it.

Tobi looks pretty chill about it in the documentary.

[jupp0r]

Totally, Rails is a great tool. So is my gunsmith hammer. I can like it for what it does without arguing it's the best thing in the world for cutting wood or joining two pieces of metal together.

[gv83]

you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks.

the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs.

I'm also curious about YOUR choice of stack at this point.

[jupp0r]

I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for.

In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast.

Nothing wrong with using a press instead of a hammer at some point, they are just tools.

[ericb]

> My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for.

What sort of web app do you have that is CPU bound?

[jupp0r]

It's an API gateway converting single digit MB-sized blobs of JSON into similarly sized blobs of JSON with a different structure.

[ericb]

The Rails app I scaled posted half a meg of JSON on every save-request every 10-15 seconds. In Rails, we parsed it, converted some parts into HTML nodes in Nokogiri, sanitized it, and saved it to both mysql and cassandra.

It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.

[jupp0r]

How many requests per second are you talking about roughly? One major problem we face is that downstream services also have performance problems and have multi second response times. While waiting for the response, a whole rails worker is sitting idle, taking up hundreds of megabytes of memory for seconds.

[arnvald]

Is there any comparably complete framework that does not need any significant adjustments even when it's used by 1000s of developers building the same app?

[jen20]

Probably ASP.NET is as close as it gets.

[neonsunset]

This, it is also on the other end of performance spectrum.

[kaba0]

Or its Java counterpart, Spring.

[jen20]

I think that's a bit unkind to ASP.NET ;-)

But yes, Spring and the various Java equivalents probably also fit the bill.

[seattle_spring]

Can confirm. Nothing worse than figuring out what sort of "magic" is affecting a route in a huge Rails app. Oh look, a before_filter in a super class 4 levels up that is defined in an include helper. But wait, why isn't it affecting all calls and only some? Ah there's another chain of filters that you only can know about if you are familiar with the older Rails version API.

Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.