Comment by kshahkshah | Hacker News Reader

Comment by kshahkshah | Hacker News Reader

I posted this same comment to /r/ruby when this article was posted there:

Having serious large scale full stack Rails and non-Rails (Py or Node) under my belt now, it has become ever so clear how productive Rails is and how much of that is the fact that Ruby actually has a f*ing standard library (directed at JS). So I'm not surprised by these numbers.

Then with gems like devise, filterrific, simple_form, cocoon, carrierwave, sidekiq, and activerecord-import I can whip together apps so quickly it just boggles my clients' minds. The ecosystem is deep, rich, documentation is good if not great and the language has several paths to getting some serious speed improvements behind it (Graal/Truffle/Substrate and JIT).

Implementing the simplest things in the node ecosystem sometimes feels like wading through molasses. I love ES6/7 but damn for 95% of projects today regardless of (anticipated) scale I'd choose Rails to start with and then split off just the things which need to be fast or fancy like Delayed Processing / MQs, ETL, any data science, etc.

Agree completely.

I enjoy programming with other languages but nothing beats Rails when it comes to getting a product out the door.

Last week I found out that a Rails app I built for a SAAS company many years ago is still running reliably and generating millions of dollars per year.

The painpoints I often run into with Ruby/Rails are concurrency and memory use. Both are addressable though.

In the time it takes to configure Webpack I can write an app in Rails. Convention. Over. Configuration.

Hah, so true.

I never learned Rails. What would you say is the best path to write a modern rails application? I learn better trough videos, btw :D

There are lots of playlists on youtube with tutorial walkthroughs. I'd go look for someone's todo app on Github and compare it to a language you know. Then write a todo app. That'll give you the initial questions you need to keep learning.

https://gorails.com/series

https://www.railstutorial.org/

I'm completely with you. Rails is still my go-to for short one-off projects that I need to build something FAST.

Hell, I even use it for quick n' dirty data analysis because working with Active Record is so easy. Rake import the data, then muck around with the Active Record models in Rails console. I honestly prefer this to working with Jupyter notebooks, unless I need graphing or something fancy out of sklearn.

"Rails can't scale" is a misnomer. Heroku and Github are RoR apps (or at least started there). At scale you might start pulling in some other services and technologies.

Preach that gospel truth. It's still as true now as it was 2000^H^H^H^H10 years ago. We're porting a project over to node now. God I hate it.

Why move? How is node better? Really honest question, I've never used either much.

Beats the hell out of me. I didn't make the decision, and objected as strongly as I could.

While I'm not expert, node goes faster and makes real time stuff like instant messaging easier.

Like for example I had a look at hackthon starters in rails, django and node and the node one has this cool dashboard https://hackathon-starter-2018.herokuapp.com/status

I think stuff like that is hard to do in rails. Also I was trying to do instant messaging in web2py and gave up and just wrote a service in node which was like 10 lines with express/socket.io.

Pragmatically I think it may be easiest to write the main app in rails of similar and link to a separate bit of node for stuff like the above.

We do precisely none of that sort of thing. Our department's workload revolves around the shifting needs of a demanding media agency, who just wants pretty looking content that's easy to manage. Everything even remotely hard they use their own media talent for. What we do is perfectly suited for Rails.

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

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?

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.

"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...

> 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 :)

> 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.

>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.

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

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.

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.

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

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

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.

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

>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...

Double Pasta, now that’s embarrassing.

>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.

> 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?

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.

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.

  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.

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.

Reply on news.ycombinator.com