[pka]

For curious onlookers: true, one can "can whip together apps so quickly", as long as:

* Your code is empirically around ~1 KLOC

* You won't have to maintain it in the future

So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother.

Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0].

I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from.

[0] https://news.ycombinator.com/item?id=17217815

[dopamean]

What does "at scale" mean? I ask because my last job was at a web host with 80,000ish paying customers. We had over 100k users of our web portal (built with Rails) which customers use to manage their sites. This was a business with over $100 million ARR around when I left last year. The user portal is the primary point of contact between the business and it's customers and we never had serious issues "scaling" Rails. It was a totally fine tool for the job.

[BOBOTWINSTON]

That is some very specific criticism to level with pretty limited evidence. Stripe might be building their own type system, as is Ruby 3.0, but plenty of apps much larger than your provided number operate perfectly.

For the record, I do think typing solves real problems for Ruby. Speaking in terms of pure productivity, it will be helpful to bring in developers who just are not experienced at working without a type system. The downside is I think most of those problems are primarily generated by inexperienced Ruby developers writing non-expressive code. Working on large code bases with Ruby is a very strange and awesome skill. The way you name things and build standards around methods/class creation ends up being a huge positive IMO.

[pizza234]

I worked on a many years old and k*10⁵ LOC Ruby application, and it's fine.

Talking about 1 KLOC and future unmaintanability is nonsense.

In order to scale, Ruby applications need very high coverage. This has nothing to do with Ruby and/or Rails though; it's a requirement of all the dynamically typed languages.

There are certainly missing functionalities that at some point will cause a roadblock (currently, threading is immature), however again, no framework can support all the possible functionalities.

[majormajor]

> In order to scale, Ruby applications need very high coverage. This has nothing to do with Ruby and/or Rails though; it's a requirement of all the dynamically typed languages.

I don't think typed languages all get you away from this. You're gonna learn things that make you want to refactor things. Your standard typed Java app isn't going to get away without tests, there, since compile != correct for the vast majority of program designs.

You might be able to get "less obviously broken" for free - logic bugs but no 500 errors from unexpected exceptions, say - but is that so much better?

[pka]

> In order to scale, Ruby applications need very high coverage.

Exactly, this is the "at enormous cost" bit I hinted at.

[akshatpradhan]

>Coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.

In case folks are wondering about what we mean by coverage...

PS. Love Rails.

[mplewis]

Writing comprehensive tests isn't an "enormous cost."

[elialbert]

Having high test coverage (especially in dynamic languages) has been industry standard for years. I haven't worked at a place that accepts poorly covered PRs in a very long time.

[akshatpradhan]

>Coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.

In case folks are wondering about what we mean by coverage...

[akshatpradhan]

Double Pasta, now that’s embarrassing.

[octernion]

as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :)

i've talked to other companies that have done similar things.

where are you getting any of this from?

[pka]

From experience.

I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests.

As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.

[octernion]

"Otherwise: don't bother." is a pretty strong statement and i think in the distinct minority.

how much of your statement is driven by that one example? that seems like a broken process or a poorly designed system (orthogonal to rails) than anything else...

[pka]

> i think in the distinct minority

I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

> that seems like a broken process or a poorly designed system

I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument. In a perfect world with perfect, non-changing requirements, no deadlines and understanding clients you can probably make Brainfuck maintainable :)

[drspacemonkey]

>I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument

If you've got a dysfunctional team and poor design, the language/framework choice isn't gonna help you. There isn't a framework in the world that will save you from tight coupling, lack of styleguide, business logic scattered all over the place, poor test suites, or monoliths made by bootcamp graduates.

[octernion]

> I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

fwiw i voted you up because i strongly believe in constructive discussion around these things. i don't think you should take that as a signal that folks support this position.

> I'm sorry, but saying that as long as your process isn't broken...

i'm merely saying that from several shops i've worked at, including instacart, with many 10k+ lines of code rails codebases, i've never seen problems like what you've described and it sounds pathological for that specific application/company.

again my (and many others') point is that rails is absolutely maintainable, even at massive scale, and even in a world with ever-changing requirements, hard deadlines, and very loosely-understanding clients, and that all that takes is doing rails the "right way" (a comprehensive test suite, reasonable architectural design), and that it is still massively productive.

[TomK32]

Isn't a exp growing user base more a problem for the support support rather than the developers?

[mmanfrin]

  Making Ruby/Rails maintainable at scale is a sisyphean task: 
  it's possible, but at an enormous cost

Disagree. I've worked at two companies now with teams of less than 6 maintaining rails apps that have handled billions in sales.

Rails can scale; the problem that Rails faces is that it is easy to get things going quickly, and lack of foresight or simple inexperience can create bombs of technical debt or scaling issues. For many years, Ruby was the lingua franca of 12-week bootcamp schools, and the code that that cohort of programmers made spanned the spectrum of quality, but it all went to production.

In other words, the problem with scaling Rails is not with the framework or with Ruby, but with the accessibility and ease of development making it easy for pernicious problems to enter the foundation of codebases.

Good ruby scales, bad ruby does not -- both exist.

[blasdel]

Another major pain point was the constant dependency churn in the RubyGem ecosystem, but all of that noise seems to have moved on to NPM along with the hype and bootcamp curriculums.

[trose]

yeah this is some nonsense. I'm at a highly successful startup serving 40,000 requests per minute on a rails app. We're starting to split out into services but that's purely from an organizational standpoint as it's becoming unwieldy for 60 developers to all work in the same code base.