Hacker News Reader

Comment by corrral | Hacker News Reader

Rails is incredibly productive for 1-3 people to write something from scratch.

As soon as everyone committing code isn't synced up with the same knowledge and solution styles, it goes to hell fast. It's bad at surviving team transitions intact, bad for onboarding once the project is past its earliest days, et c.

View on HN

Now, see, I would argue EXACTLY the opposite. I worked (briefly) for a Rails "house." I was assigned to a project that someone who had left the company had been working on, and told to add payment processing. I started working through the idea, putting stuff in the places it should go throughout the stack. About halfway through the process, I finally noticed some code that looked almost exactly like my function, "below the fold" of the text editor window. Then I started noticing that I had duplicated the little snippets of code needed in many files. They looked almost the same, and they were in all the same files. In fact, I realized that ALL the code to enable the processing was already done, and all I had to do was expose it on the page. To me, it was a crystal clear example that each bit of code needed to do something in Rails has a "correct" spot, and it's hard for me to believe that anyone with a nominal understanding of Rails wouldn't grok the organization, and naturally do things "the Rails way."

I've worked on four or five Rails codebases. All did things "the Rails way". All were quite different, and none were plainly incorrect.

It's interesting though how you had to re-implement a large part before you were able to discover the existing code that does what you had needed.

Discoverability problems are not specific to Rails, but may have something to do with convention over configuration, though.

My experience doing agency work with Rails has been similar. Love or hate the opinionated nature of it, switching projects was fast because generally you'd just know where any given thing's home would be.

That is every project when the team is dysfunctional. Your language won't save you.

Some languages and ecosystems can be more helpful, though, even if none can save you. Rails is memorization-heavy and doesn't have static types to aid in navigation & reading. Its runtime auto-magic even resists grepping. Auto-imports mean you don't even get a decent list of which sources are contributing to a given file's behavior.

It's also the case that different teams can write it pretty differently, depending on gem choices and which Rails features they lean on. Plenty of other languages and ecosystems are like that, too, but all the above stuff means Rails is exceptionally bad, in that regard.

This is a succinct illustration why magic [1] in engineering is an anti-pattern.

[1]: https://data.whicdn.com/images/198477032/original.jpg

I’ve worked on a large rails code base for 10 years, with hundreds of developers. It hasn’t been any worse than any other language I’ve used.

The worst code bases I’ve worked on used statically typed Java.

> Rails is memorization-heavy and doesn't have static types to aid in navigation & reading.

Except of course that now it does.

So worst case if you inherit a codebase without static types added you can use gradual type as you get to know it.

Same happens even on statically typed language: Spring

Reply on news.ycombinator.com