[jupp0r]

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request.

In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency story (don't tell me how great Fibers are please). There are plenty of alternatives (nextJS, Remix, etc).

On top of that, the prevalence of OO antipatterns in the Ruby community (global mutable state, prevalence of inheritance over composition, complete disregard of SOLID) will eat up any initial productivity gains pretty fast.

[rco8786]

My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to.

The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something.

My opinion, of course.

[lawn]

Sounds like the language doesn't have "great concurrency" if you go out of your way to discourage it?

[jupp0r]

You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.

[rco8786]

Where did I say anything like that?

[jupp0r]

"The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something."

The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging with the Rails community.

I get it that most startups in the early phase don't care if a request is taking 200ms or 1s and should just go with whatever is easiest to implement. The tendency to generalize this thought to mean that nobody ever needs to care about these problems is crazy though.

[rco8786]

I honestly feel like you're responding to an entirely different person, despite the fact that you quoted my post.

Rails can scale horizontally just fine for a huge, huge majority of business cases. If you have a business critical use case that truly needs however many thousands of things done in a tight loop inside a single process...obviously Rails is not the tool you should be using.

I did not say "the ability to optimize something is a trivial niceity". I said "concurrency often gets in the way more than it helps unless you're trying to optimize something". I'm not sure if you're purposefully misrepresenting my words, but it does feel like you are especially given the "so you never make HTTP requests" comment you started this thread with.

[jupp0r]

I also have the feeling that you are talking to a different person. I'm talking about latency, you are talking about bandwidth. I'm talking about concurrency, you are talking about parallelism.

You can scale up any Rails app super easily by throwing money at the problem, it's trivial. When a single page load or API request to it takes 20 seconds, it doesn't help you if you have 1000 servers that can respond to hundreds of requests in 20 seconds each, when you need that request served in 500ms. This means that while serving a single request you might need to do things concurrently (like make an http request to an authz service and do a db query at the same time).

[hakunin]

Just out of curiosity, what are you doing with a great concurrency story in a company you start in 2024?

[jupp0r]

Make HTTP calls to OpenAI? Pusher? DynamoDB? KMS? SQS? Make a datababse query? Anything that you cannot or do not want to run in your monolith service.

You make it sound like it's sufficient to have concurrency support in 2024. My point is that it's necessary.

[hakunin]

Http clients have pipelining for parallel requests that doesn't require threads. Database calls in Rails 7 now have `load_async`. You can still have other services, outside of Rails. Would that cover it?

P.S. I'm a huge fan of Elixir/Phoenix, but didn't find the big need for concurrency in practice that Rails doesn't address somehow.

[jupp0r]

Yeah, there are small, niche solutions for solving concurrency for very specific use cases vs general support for this in the language. This doesn't help you when you are using the AWS SDK to make HTTP requests or when you want to hide latency of making a DB query and and HTTP request concurrently.

I'm currently working on a large Rails App in my day job and lack of concurrency support is a major limiting factor for the growth of the whole company (~$10B market cap).

[hakunin]

I understand your general point, but these solutions are not niche. They cover almost everything needed in web dev. The niche problems are the ones that arise at scale, which is when a business typically has the resources to solve them. (Hint: you don't have to solve them in Rails).

Large app / company challenges don't apply to new apps. Statements like "I wouldn't start a new app without a great concurrency story." or "I wouldn't start a new app without microservices." etc don't make sense, because new apps have different priorities (i.e. finding the fit, surviving, staying relevant).

I went through a phase of building Elixir/Phoenix apps for 3 years, thinking that I will switch permanently, but ended up coming back to Rails due to higher productivity in that stack. This was in 2015-2018, so maybe Elixir/Phoenix has gotten more ergonomic since. I'm not sure.

[jupp0r]

You can build a great NodeJS monolith, be very productive and not end up in a corner where you have to spend years of effort fixing your early technology choices down the road. It's not a zero sum game and completely rewriting millions of lines of business logic that your company is relying on for revenue is a hard sell.