[berkes]

Negative tone aside, indeed: the problems that Rails "solves" here have long been solved in computing. Not just .net. In Ruby too, just not in Rails.

Event-based architectures such as event-sourcing, -listeners, -subscribers, message-buses, actor pattern. All of them solve the problems that Rails tries to solve with delayed jobs. But does it with different tradeoffs.

Rails is first and foremost an MVC setup with a heavy and tight coupling to the database. That is a poor fit for apps or domains with lots of sequential logic, messaging, services or orchestration. Rails is perfect for reasonable simple "CRUD", its less perfect for "CRUD+business-logic" and a very poor fit for complex domain models with (eventual) consistency and/or message passing.

For the middle-scenario, Id -personally- forego Rails, and choose or build an archictecture that focuses more on logic than on "getting stuff in and out of a database". But I see why people will choose Rails there too, and then bolt the logic and consistency on top of it.

[toomanybeersies]

As a counterpoint, I used to work on an automated testing tool for websites and mobile apps, which was built entirely using Rails (with Resque for background jobs).

We had customers setting up tests which could cover thousands of pages and run for hours (or even days).

Sure, Rails probably wasn't the ideal tool for the job, but it worked fine.