[nobleach]

As in will you find plenty of recruiters hunting for Rails developers? Absolutely. I've seen plenty of startups locally (Salt Lake/Provo) that are green-fielding with Rails. I've also seen later-stage startups that are transitioning their Rails monoliths to Elixir - and they're trying to hire folks that are willing to work on 4 year old Rails monoliths. That's not a bad thing is Rails is your thing.

I enjoyed Ruby as a language quite a bit. Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.

So, yes, there will be plenty of Rails projects to work on for the foreseeable future. The only concern I'd have is if you're being asked to work on a very old code base. That can get really hairy, really quickly. But that's the case with any language/stack.

[weatherlite]

> Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.

What part of Rails doesn't scale well? As I see it any mediocre devops can scale just about anything with some basic Kubernetes know-how, doesn't matter of it's Ruby or Java.

[nobleach]

It absolutely does. When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win". One bumps up against the node count that is hit by the load balancer. (NodeJS experiences this quite a bit too). Rails excels in heavily cached configurations. This requires less volatile data.

My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it) - and I would argue that it's more of an effort than some DevOps personnel updating a pod count - it's fairly easy to start with something that is already very performant. SpringBoot is an opinionated framework for Java that has very good raw performance. I'm simply advocating that it doesn't hurt to start with something that's already pretty good. That's not premature optimization, it's just making wise decisions from the start.

[weatherlite]

> My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it)

That's what I'm saying - you don't need to "work hard" to tune Rails in 99% of cases - your bottlenecks (if any) will probably be in the database layer. k8s simply solves it, so unless your argument is "infrastructure costs" or something I don't agree with your case. Shopify has such tremendous scale I think its ridiculous to use it as an example for the average company.

> When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win".

Why does it cease to be a win? Everyone is doing it no matter what stack they are on. So with Rails you might have a few more pods - for any startups that's going to succeed the cost is simply negligible.

[nobleach]

Yes, scaling horizontally can be quite expensive. For a startup that begins their journey with Rails, and finds out quickly how expensive that is, it can be a show stopper. Shopify and Stripe are used as an example simply because I want to agree that it is possible - given a ton of resources.

So, if I could tell you, that for your next startup, you could start with something that is easier and cheaper to scale (I find "a few more pods" very disingenuous as many benchmarks say otherwise), why would you choose something that requires a lot more resources? Because Rails is neat? I just don't see the allure at that point. It's why we're seeing companies like Podium, Divvy, PagerDuty move away from it. It's great to get a proof of concept out the door. So many stories are out there of folks that are moving away from it for their "next step".

[weatherlite]

We are not going to agree here probably. Another anecdote - because of our company's microservice/k8s architecture each dev works on their own k8s cluster. While some services are shared - most are not. That means we pay more for dev infrastructure than our production bill! So if optimizing infra from the start is the game - why is everyone doing micro services?