News for hackers. Stuff that matters.
Re:Why We’re Sticking with Ruby on Rails at Gitlab by corrral on Monday June 13, 2022 @02:49PM (#31729857)
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.

Re:Why We’re Sticking with Ruby on Rails at Gitlab by jshen on Monday June 13, 2022 @03:49PM (#31730820)
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.

Re:Why We’re Sticking with Ruby on Rails at Gitlab by Lio on Monday June 13, 2022 @04:03PM (#31731028)
> 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.

Re:Why We’re Sticking with Ruby on Rails at Gitlab by fomine3 on Monday June 13, 2022 @09:13PM (#31733684)
Same happens even on statically typed language: Spring
Re:Why We’re Sticking with Ruby on Rails at Gitlab by nine_k on Monday June 13, 2022 @03:08PM (#31730158)
This is a succinct illustration why magic [1] in engineering is an anti-pattern.

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