4 ms·

"Programmer happiness" is such a provocative point. Anyone who is giving Rails a serious look, should take the time to read Eloquent Ruby. When Rails prioritiz

"Programmer happiness" is such a provocative point. Anyone who is giving Rails a serious look, should take the time to read Eloquent Ruby. When Rails prioritizes programmer happiness, what Rails is really doing is prioritizing the happiness of the lone rockstar developer who is the sole writer, owner, and operator of that codebase. You can build some code that is, yes, quite eloquent. It will be a complete work of art (and yes, Eloquent Ruby was quite illuminating at how Ruby uniquely helps you to write code as art). It will read like English. Your productivity will be phenomenal. You will feel like you can cure cancer by yourself. But all that flies out the window once you need to share that code with someone else, or inherit a codebase from someone who thought of himself as Da Vinci and his codebase as a modern Sistine Chapel. Then it becomes a colossal pain. Because while the codebase itself might be art, the shared context for how to work within that art is nowhere to be found.

berkes 3y ago
This resonates with me. With the added pain that "me today" and "me two years ago" are often different people too. Rails shows this exact same collosal pain over longer period of time. Rails optimizes my happiness today by trading it in for my happiness in a few years.
seattle_spring 3y ago
Oh boy does this comment resonate with my experience. Several times now I’ve had incoming Rails enthusiasts insist that RoR is the absolute best solution to all problems. Inevitably, once the project has more than 3 engineers, it becomes a disjoint, indecipherable mess that eventually gets re-written entirely. I’ve said it once and I’ll say it again: Rails is the least-scalable framework ever when it comes to # of engineers. Someone is surely going to respond “you can just add more instances!” Not what I’m talking about, though it’s bad in that department too.
- mvdtnz 3y ago
  And I'll bet my bottom dollar that every developer who joined the team and was appalled at the state of the codebase said something like "if they just did Rails right it wouldn't be so bad!". Ad infinitum.
  - seattle_spring 3y ago
    This rings so true that it made me laugh out loud when I read it. I’ve heard this line from literally every Rails-engineer-peer I’ve worked with that I can think of, usually about codebases that they were in charge of.
- TenJack 3y ago
  I’m curious, what do you think the most scalable backend framework is (engineer wise)?
- eviluncle 3y ago
  what kind of codebases were you working on? I've had the pleasure of working on 2 big companies using rails, each with well over 50 engineers and the code base was so relatively easy to jump into. The beauty of rails is that if you follow its guidelines, anybody can jump right in. what alternatives do you find are better when scaling up with more engineers?
  - stouset 3y ago
    The biggest issue I’ve seen is when companies hire 4 junior engineers with zero or minimal Rails experience to bootstrap their product, let them loose, and… yeah everything quickly becomes a mess. Nobody understands the conventions so they cargo cult whatever they found from a blog that was last updated in 2013. Or they find novel and extraordinary solutions to problems that the framework literally already solved. Or they have zero experience modeling things in a database—much less doing it the way ActiveRecord encourages—so every battle is always uphill. The biggest problem with convention over configuration is when you have a team where nobody understands the conventions. But what else do you expect?
    - seti0Cha 3y ago
      I don't believe I've ever seen 4 junior engineers who don't know what they're doing build anything other than a mess. I don't have any experience with rails, so I can't say whether the mess would be worse, but those engineers are definitely going to make one without guidance.
      - stouset 3y ago
        My point precisely :) I will happily concede, though, that I do think in that sort of situation that Rails can very easily become worse than other languages/frameworks.
hakunin 3y ago
You’re right that if your goal is to write English-like code, then clarity may suffer. The same is true if your goal is to write consistent strict mechanical code. The only goal I think that makes sense, is to go for clear code based on shared context with your team. That said, I don’t see how the rails doctrine inhibits one’s ability to write clear code.
danmaz74 3y ago
I've been using Rails for over a decade and worked on lots of different Rails code bases. Contrary to what you're saying, my experience is that the philosophy of "convention over configuration" usually makes it very easy to delve into a Rails project you don't know, as long as the developers didn't decide to go off the rails with experimentation. Then of course you can find badly written code in any language, and if a quirky would-be rockstar creates a project thinking about art instead of readability and maintainability, they can definitely create an unmaintainable mess with Ruby on Rails - there is nothing preventing you from doing that.
- solatic 3y ago
  > as long as the developers didn't decide to go off the rails with experimentation As the number of developers on the project increases, said probability approaches 1 ;)
weaksauce 3y ago
Eloquent Ruby is a simply fantastic book that should be required reading for everyone. and yeah inheriting someone else's codebase that has a gem that installs some new dsl that you have no idea where it came from can be a nightmare.
- ezekg 3y ago
  If you’re ever curious about where a method comes from, you can use method(:some_new_dsl).source_location [0]. [0]: https://docs.ruby-lang.org/en/3.2/Method.html#method-i-source_location https://docs.ruby-lang.org/en/3.2/Method.html#method-i-sourc...
  - weaksauce 3y ago
    oh yeah i've definitely used that in the past. just saying you have to get the code to run to that point and it's just a pain to figure out what is going on sometimes. a lot of times it's easy enough by browsing the gem file. however things get more murky when you have some dynamically generated methods and it just tells you the thing was created by eval.
JeremyNT 3y ago
This is so far divorced from my experience, like we're not even thinking about the same software. Rails is very opinionated, and when I've encountered new rails code bases they are easily legible to me and can readily be understood. Even outside of rails, the largest real pitfalls of clever ruby I've seen are related to gratuitous use of metaprogramming, which one can sometimes encounter if you need to maintain or find a bug in a gem you aren't familiar with. Maybe your problems weren't with rails, but with the programmers of the code bases you were looking at? I believe it's possible to write unmaintainable code in any language.
1letterunixname 3y ago
It's optimized for the happiness of the person who throws together an app in a month, sprays tech debt and monkeypatches everywhere, and then leaves everyone else to pickup the check. There's lots of old, broken shit in the Ruby ecosystem and stuff is constantly breaking because of churn and the lack of meaningful, accessible gradual/static typing. (Elixir roughly in the same boats above.) It also doesn't help that some of the gatekeepers of Rails/Ruby have megalomaniac, reactive personalities who make interacting with them sheer misery and CWOT. If you want what looks like Ruby compiled, there's Crystal. Go and Rust backend frameworks exist also.
ezekg 3y ago
Strong disagree. Typically, Rails apps are easy to grok. Just look at Mastodon, or Discourse, or Lobste.rs, or GitLab. All pretty easy to understand for somebody familiar with Rails, because they follow the Rails convention over configuration doctrine (I personally read these code bases often when researching how others implement certain things).
herbst 3y ago
Interestingly enough I think the opposite is the case. The 'MVP' and the general structure Rails gives you makes it easy to follow any trail. The context is mostly obvious and the 'artistic language' of the original coder often easy to understand. Maybe I've been just lucky in the at max 20 or 30 larger projects I worked on so far.

berkes 3y ago

This resonates with me. With the added pain that "me today" and "me two years ago" are often different people too. Rails shows this exact same collosal pain over longer period of time. Rails optimizes my happiness today by trading it in for my happiness in a few years.

seattle_spring 3y ago

Oh boy does this comment resonate with my experience. Several times now I’ve had incoming Rails enthusiasts insist that RoR is the absolute best solution to all problems. Inevitably, once the project has more than 3 engineers, it becomes a disjoint, indecipherable mess that eventually gets re-written entirely. I’ve said it once and I’ll say it again: Rails is the least-scalable framework ever when it comes to # of engineers. Someone is surely going to respond “you can just add more instances!” Not what I’m talking about, though it’s bad in that department too.

mvdtnz 3y ago
And I'll bet my bottom dollar that every developer who joined the team and was appalled at the state of the codebase said something like "if they just did Rails right it wouldn't be so bad!". Ad infinitum.
- seattle_spring 3y ago
  This rings so true that it made me laugh out loud when I read it. I’ve heard this line from literally every Rails-engineer-peer I’ve worked with that I can think of, usually about codebases that they were in charge of.
TenJack 3y ago
I’m curious, what do you think the most scalable backend framework is (engineer wise)?
eviluncle 3y ago
what kind of codebases were you working on? I've had the pleasure of working on 2 big companies using rails, each with well over 50 engineers and the code base was so relatively easy to jump into. The beauty of rails is that if you follow its guidelines, anybody can jump right in. what alternatives do you find are better when scaling up with more engineers?
- stouset 3y ago
  The biggest issue I’ve seen is when companies hire 4 junior engineers with zero or minimal Rails experience to bootstrap their product, let them loose, and… yeah everything quickly becomes a mess. Nobody understands the conventions so they cargo cult whatever they found from a blog that was last updated in 2013. Or they find novel and extraordinary solutions to problems that the framework literally already solved. Or they have zero experience modeling things in a database—much less doing it the way ActiveRecord encourages—so every battle is always uphill. The biggest problem with convention over configuration is when you have a team where nobody understands the conventions. But what else do you expect?
  - seti0Cha 3y ago
    I don't believe I've ever seen 4 junior engineers who don't know what they're doing build anything other than a mess. I don't have any experience with rails, so I can't say whether the mess would be worse, but those engineers are definitely going to make one without guidance.
    - stouset 3y ago
      My point precisely :) I will happily concede, though, that I do think in that sort of situation that Rails can very easily become worse than other languages/frameworks.

hakunin 3y ago

You’re right that if your goal is to write English-like code, then clarity may suffer. The same is true if your goal is to write consistent strict mechanical code. The only goal I think that makes sense, is to go for clear code based on shared context with your team. That said, I don’t see how the rails doctrine inhibits one’s ability to write clear code.

danmaz74 3y ago

I've been using Rails for over a decade and worked on lots of different Rails code bases. Contrary to what you're saying, my experience is that the philosophy of "convention over configuration" usually makes it very easy to delve into a Rails project you don't know, as long as the developers didn't decide to go off the rails with experimentation. Then of course you can find badly written code in any language, and if a quirky would-be rockstar creates a project thinking about art instead of readability and maintainability, they can definitely create an unmaintainable mess with Ruby on Rails - there is nothing preventing you from doing that.

solatic 3y ago
> as long as the developers didn't decide to go off the rails with experimentation As the number of developers on the project increases, said probability approaches 1 ;)

weaksauce 3y ago

Eloquent Ruby is a simply fantastic book that should be required reading for everyone. and yeah inheriting someone else's codebase that has a gem that installs some new dsl that you have no idea where it came from can be a nightmare.

ezekg 3y ago
If you’re ever curious about where a method comes from, you can use method(:some_new_dsl).source_location [0]. [0]: https://docs.ruby-lang.org/en/3.2/Method.html#method-i-source_location https://docs.ruby-lang.org/en/3.2/Method.html#method-i-sourc...
- weaksauce 3y ago
  oh yeah i've definitely used that in the past. just saying you have to get the code to run to that point and it's just a pain to figure out what is going on sometimes. a lot of times it's easy enough by browsing the gem file. however things get more murky when you have some dynamically generated methods and it just tells you the thing was created by eval.

JeremyNT 3y ago

This is so far divorced from my experience, like we're not even thinking about the same software. Rails is very opinionated, and when I've encountered new rails code bases they are easily legible to me and can readily be understood. Even outside of rails, the largest real pitfalls of clever ruby I've seen are related to gratuitous use of metaprogramming, which one can sometimes encounter if you need to maintain or find a bug in a gem you aren't familiar with. Maybe your problems weren't with rails, but with the programmers of the code bases you were looking at? I believe it's possible to write unmaintainable code in any language.

1letterunixname 3y ago

It's optimized for the happiness of the person who throws together an app in a month, sprays tech debt and monkeypatches everywhere, and then leaves everyone else to pickup the check. There's lots of old, broken shit in the Ruby ecosystem and stuff is constantly breaking because of churn and the lack of meaningful, accessible gradual/static typing. (Elixir roughly in the same boats above.) It also doesn't help that some of the gatekeepers of Rails/Ruby have megalomaniac, reactive personalities who make interacting with them sheer misery and CWOT. If you want what looks like Ruby compiled, there's Crystal. Go and Rust backend frameworks exist also.

ezekg 3y ago

Strong disagree. Typically, Rails apps are easy to grok. Just look at Mastodon, or Discourse, or Lobste.rs, or GitLab. All pretty easy to understand for somebody familiar with Rails, because they follow the Rails convention over configuration doctrine (I personally read these code bases often when researching how others implement certain things).

herbst 3y ago

Interestingly enough I think the opposite is the case. The 'MVP' and the general structure Rails gives you makes it easy to follow any trail. The context is mostly obvious and the 'artistic language' of the original coder often easy to understand. Maybe I've been just lucky in the at max 20 or 30 larger projects I worked on so far.