[stevebmark]

Concerns are the best example of the flaws in Rails and Ruby. The fact that DHH came up with a mixin applied at runtime as the solution to organizing Rails apps is frustrating. Other programming ecosystems have rightly moved away from mixins and do-everything-dynamically, along with moving away from mixing data and methods that self-mutate that data.

Having worked on large real world Rails apps, concerns are indeed a poor pattern in practice. They introduce hidden, untraceable dependencies, can clobber each other silently, make it difficult or impossible to understand where methods come from, and bloat classes into super coordinators, when "models" should only be data. Combine that with Ruby's horrible preference for metaprogramming and you get unmanageable code.

PS: If you work at a company as big as Github that can afford to literally employ Ruby core maintainers, then you are welcome to reply with "but it works for Github!"

[joelbluminator]

"Combine that with Ruby's horrible preference for metaprogramming and you get unmanageable code": Is it impossible to write maintainable code in Ruby or is it just teams of people with varying skill levels working under pressure and hard deadlines? Do you think the average Rails app is less maintainable than the average Node / PHP or even Java app? I'm not so sure.

[dhagz]

It's teams of people with varying skill levels under time pressure.

Ruby is a language where projects can suddenly bloom with hyper-complexity if you're not careful. You really have to strictly adhere to a style guide and have seniors who can catch the violations automated checkers like Rubocop can't.

[joelbluminator]

It might be a bit more pronounced in Ruby, but I doubt this doesn't happen a lot in javascript / python / whatever language actually. You always better have at least a couple of seniors in each team that go over every PR and maintain the project's health. No getting around that no matter the language. Now languages like php / ruby / js are notorious for their low code quality but that's less about the language and more about how and where they're used: tons of startups, young people in the beginning of their careers, pressure to find market fit etc. I'd be surprised if .net / java / python projects don't turn into crap under these conditions. The worst code I've produced was written like that and I really doubt the tech stack would have made any big difference in the quality of code I produced.

[cageface]

I've been working on Ruby apps again lately after spending a few years in the iOS world. I don't miss iOS at all but moving back to a slow, dynamically typed language like Ruby after getting used to Swift is like trading in a Tesla for a Model T. Ruby was great it its day but I think we can do better now. Maintaining large Ruby codebases is no fun.

[ultrarunner]

No fun for you, maybe. And I can see where you’re coming from. I often find it very fun, though, which has prevented me from porting an API to another language like Go or (gasp) Swift. Ruby gives a lot of flexibility, and in my line of work (especially with covid mitigations) there are lots of immediate change requirements; flexibility is very important. That flexibility provides the ability to shoot yourself in the foot (and I’ve surely done it), but it also allows us to pull off events that have suddenly changed with little warning. I like that.

[theonething]

> pull off events that have suddenly changed with little warning.

Excuse my ignorance. What are the events you reference here?

[ultrarunner]

I work for an event company, and in many cases much of it is orchestrated by Ruby code, including a few rails apps.

[theonething]

aha. I wasn't sure if you were taking about events on the software side.

[ultrarunner]

Imagine the naming conventions on the software side :)

[joelbluminator]

Not really sure what's Ruby's "slowness" has to do with anything? Were you having performance problems with Ruby or did you just throw in it being "slow" to prove a point? I worked on quite a few Rails apps for 6+ years and Ruby's speed was never an issue.