Comment by horsawlarway | Hacker News Reader

Comment by horsawlarway | Hacker News Reader

Parent Full thread

For a single person project, Rails is decent.

I actually think RoR is an utter garbage fire the second you have a team of 3+.

Also, to be blunt, RoR most reminds of me of the old Microsoft web frameworks at this point (asp.net, before core). It's all pre-configured. You have very few structural choices to make, and you can focus on the actual project meat right away. The problem, coming in as someone without experience in the platform, is that documentation is becoming incredibly fragmented.

The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth.

Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works.

It's eerily reminiscent of microsoft products that tried to the same thing - because "The best out of the box experience" changes every year or three, and they all try to meet current expectations.

So long post aside, having used Rails for a while professionally, but also having come in with a LOT of alternative experience (mainly Node/TSNode/C#/Golang) I find it functional, but fairly unimpressive, for small projects.

Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot.

> I actually think RoR is an utter garbage fire the second you have a team of 3+.

This isn't a a Rails issue, I have worked on teams with 30+ members with no problems. It is an organizational problem.

> The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth.

I cannot remember the last time I needed to touch a Rails configuration truthfully. I prefer not to touch any configuration. This is a subjective opinion, but less I need to configure the app over time the more stable the configuration is. The configurations don't change that much, you expect them to change during major version releases. I don't know how often you change Rails versions.

> Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works.

Ok this one I am going to strongly disagree with. Rails has some really good documentation, and solutions are very easy to find for a lot of problems.

> Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot.

But Ruby is not a typed system out of the box, it is supposed to be duck typed. Now while I might have a leaning towards typed systems also myself, it is not a limitation of the language and layering types on top of duck typing erodes some of the flexibility.

> It is an organizational problem.

Of course it is. But nothing happens in isolation.

Rails requires a lot more effort to keep a team in sync than an equivalently sized codebase in a typed language.

To get the same quality deployment in production we needed extensively customized linters, a broad suite of tests, and much more frequent QA review with Rails.

None of those are bad, but they're a lot of effort to corral folks away from the (sometimes awesome) but usually frustrating amount of variety Ruby allows in expressiveness. Plus you need the testing/qa to stop a larger and larger number of bugs, particularly in cross cutting concerns, that are introduced by the lack of type checking.

Rails is 100% the "Solo developer goes 'Brrrrr!'" framework. It genuinely starts to be a drag compared to the alternatives on large teams.

Of course you can make it work. But generally companies "Make it work" as they migrate to a more serious solution.

When I was younger, that tended to be Java/C#, but lately seems to be more towards either Typescript if performance isn't likely to be an issue or GoLang otherwise. Recently worked with a Rails team looking into moving to Rust, but they eventually settled on Elm instead.

Would still love to get information about how Sorbet is going. Seems like it might be a viable answer at some point.

Reply on news.ycombinator.com