Ah, that's an interesting perspective. Having written and supported websites in both Java and Ruby (plus some other languages), I think that your perspective is valid. Long term costs are worth considering. However, sometimes you can take a long term hit in order to deliver quickly.

> compared to the life of that webapp in all situations where that webapp is anything serious.

Actually there is a situation where the short term life of the webapp matters far more than the long term. That's when you are not sure if there is going to be a long term. This could be a startup, a spike to explore a new business model, or even just a prototype of an internal app.

In all those cases, delivering something that has value in a short time outweighs the value of something that might be more supportable/extensible in the long term.

You're absolutely right.

We should all over engineer our applications by picking the most complicated stack possible because the long term goal may slightly benefit the short term goal of you know.. actually making money out of our business.

Why pick a simple Rails + Postgres stack when you can setup Oracle + Java because you will require enterprise level scaling for your first 1-100k users

Oh and just for the record, I am sure you are already aware but Rails gets you very..very far. Github, Gitlab, Shopify, AirBnb, Basecamp, Groupon,.. I could go on.

My vote goes to rails.

That's like saying that php is a good choice because so many sites use it. Php is never a good choice. Neither is Rails.

Shower me with downvotes. IDGAF; Ruby is rubbish.

I entirely disagree with this.

Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term.

Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.

Everytime I say anything on this orange website anymore it is immediately voted down.

I guess the orange website isn't for me anymore.

Well, your comment contained a bit of a generalisation. It may or may not be true depending on the size of the app, its purpose, the number of developers, their level of experience, and a bunch of other factors.

The response contained a generalisation too. Horses for courses.

I agree.

I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.

But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.

These days I'm far less likely to give up simplicity so easily.

Assuming we’re talking about a startup, the expected lifetime of your product is ~0 and so is the number of customers. If you’re somehow lucky enough to ever have so many users that you have issues with rails, you will have the money (VC or otherwise) to deal with it.