The Rails Doctrine | Hacker News Reader

The Rails Doctrine

rubyonrails.org

143 pointsthunderbong55 comments

"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.

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.

I’m curious, what do you think the most scalable backend framework is (engineer wise)?

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?

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?

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.

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.

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.

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.

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.

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.

> 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 ;)

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.

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-sourc...

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.

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.

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.

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).

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.

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.

As someone who doesn’t use rails at all, I found this refreshing. In my day to day, I’m exhausted by the endless arguments that arise from using an unopinionated framework, the likes of fast api or flask. I’m not sure that these argument provide any value to the users we build for. I wish more frameworks would layout their values like this and let the developers who use them stop talking about these “invaluable” points.

There’s a lot of value in having decisions made for you ahead of time. Nonetheless, decision fatigue is one of the things that annoyed me most about Rails after working in it for the first few years of my career; the flexibility and “expressiveness” of Ruby syntax makes it so writing code is a series of pointless decisions. Do I use parentheses in my function call? Do I use do/end or braces? Array indices or helper methods like .third? I’ve grown to question the value of this sort of thing. Rubyists used to say that various Ruby frameworks were DSL’s (DHH here restrains himself to saying it “looks like” a DSL) but frankly, leaving the parens off of method invocations isn’t a very convincing magic trick once you know how it works, and it’s not worth having to second guess whether to use parens every time you want to call a method.

…or you can use a standard formatter like standardrb and end that conversation entirely.

You’re right, it’s easy to bikeshed on which syntax constructs are more elegant, but the Ruby ecosystem provides tools to eliminate the need for that conversation.

> …or you can use a standard formatter like standardrb and end that conversation entirely.

This is the solution I've gravitated to in other languages (e.g. Black, gofmt), but that was after my time in the Ruby ecosystem.

That's interesting. I've had the opposite reaction to those many little decisions: it doesn't matter. Do whichever you like. All of the options are sufficiently readable.

It matters somewhat. I had a coworker who used to avoid parens any time it was possible which I found incredibly annoying:

  "foo bar"
    .split(" ")
    .map(&:capitalize)
    .join " "

There is really no advantage to not putting parens for the `join` call. Meanwhile, it makes modification a pain as well as makes for some ugly diffs.

But as a sibling comment mentioned: just use a linter.

the convention that i think most rubyists gravitate toward is to always include parens for method calls when calling something that takes a parameter. omit if there are no parameters.

It is, and it's how I do it when I write Ruby. I was just responding to "it doesn't matter" part of the parent comment. If you decide not to use parens, then you get situations like the one I illustrated where you have to use parens for chaining then you're left with a decision about what to do with the last one.

Why are the parens important in this example?

You can't chain without parens.

  # Does not work
  "foo bar"
    .split " "
    .join " "

There was a proposal to introduce a "pipe" operator at one point which was shot down [0]. It wasn't actually a pipe operator at all and really just an operator that would have made the previous syntax possible (|>, instead of .)

[0] https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d

Yes, definitely omit parentheses when calling a method without arguments.

For calls with some non-block arguments, it's not so clear-cut as "always include parentheses".

Some methods are so prevalent that they almost become part of the language "syntax", even though there's nothing syntactically special about them. For example, you rarely see parentheses used on calls to `attr_accessor` or `private`:

  class Cat
    attr_accessor :fluffiness
    
    private def plan_world_domination
      # TODO
    end
  end

I think parentheses around `private(def some_method ... end)` would be especially non-idiomatic. Even though passing the result of the `def` expression to the `private` method is exactly what's happening.

Another place where it's usual to omit method call parentheses is on embedded DSLs. For example, in RSpec it's uncommon to include parentheses on calls to `describe` or `it`.

  describe "RSpec DSL" do
    it "looks neater without parentheses" do
      # ...
    end
  end

yeah there will always be edge cases but those are few and why i hedged with gravitate toward. private feels like a part of the language actually like an if statement instead of a method though.

While those decisions are completely meaningless as far as performance or correctness of your program goes, they do have value for readability. One way to deal with them is of course to install something like standardrb and never think about it. The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.

> The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.

Yes, that's the extra decision step in my main workflow loop that I'd like to cut out whenever possible.

I think in general it's almost impossible to cut out human consideration and still get auto-clarity. With an auto-formatter you gain a little speed and lose a little readability. I think most people are really arguing about whether this trade off is worth it. Some are arguing that any readability gains are minimal (and debatable), but then it's like arguing that there's no point to being a better writer, and information can just be auto-formatted for human consumption with a set of standard heuristics. I guess we might actually get this world once everything is written by ChatGPT to maximize consistency. But then, how can we both claim to like complete and total mechanical consistency in code, and dislike it in any other form of writing? If code can be written more than one way, shouldn't we optimize it the same way for fellow devs as good writers would for their readers?

To be blunt with you, I think Rubyists cling to optional parentheses for purely aesthetic reasons; all of the supposed Ruby “DSL’s” that are just method invocations without parentheses would be no less and arguably even more clear and readable with parentheses.

Frankly, parentheses was the last thing on my mind. I typically use them by default, and remove them in cases where it might make sense.

Mostly I was thinking about stuff like arrangements of hashes, arrays, method arguments, naming of methods and variables, various styles of method chaining, block usage, etc.

Sure, but that kind of stuff is not generally unique to Ruby.

I stopped at the first point out of sadness. I've worked on the JVM space for 19 years. For the last 1.5 years, I've been working in an org that uses Spring Boot and the code, configuration, and general designing of the applications feels horrendous. I know spring boot was the 2nd (or 3rd?) attempt of Spring to get a quick development framework simiar to Rails (Spring Roo was the first I think) but my gosh it has soo much magic, and it's so slow. Starting up a app can easily take 20+ seconds, and the full start/stop cycle can take 60+ seconds. On production we often have apps taking longer than 2 minutes to boot up and the only thing they do is open a few connections to the database and to a messaging broker (both which are very fast). The component scanning "feature" is a disaster.

I love ruby and find it and I know Rails also has some magic, but I love my types. I'm glad I'm going back to do something sensible in a few months. Probably Kotlin + http4k.

I like what Rails offers. I like it to the point that I am now creating a SaaS template[0] that packs all of Rails has to offer.

That includes using frameworks like Active Storage, features like CurrentAttributes or defaults like Minitest.

Some of it is controversial or not favoured by community. Not many people experience Rails with the core value it's designed around which is a shame!

It's great you can replace certain parts, but should you?

[0] https://businessclasskit.com/

yes! i'm doing something similar on a personal project, trying to leverage the rails conventions as much as i can, and so far, it's been a real net gain in productivity from something like rails 5.2/6. i'm using the bleeding edge rails 7.1.alpha, which has a number of niceties like built-in password challenges, template locals, common table expressions in AR, and default dockerfiles (which i don't use), pluse better support for encrypted attributes and (postgres) enums. i'm also using some new-ish ruby features like endless methods, which is surprisingly useful for thinking about how to make methods more atomic and modular.

Hacker news today:

6. Rails Cheatsheet

7. The Rails Doctrine

Interesting coincidence. Right on top of each other too.

This happens routinely on HN. People read one thing, which causes them to remember or discover something else on the same topic, and submit that. People likely to upvote one will likely upvote the other. Frequently, that second submission started as a top HN comment in the first submission.

As an ex-Rails developer, It's unlikey I'd return.

Rust/Go/Elixir/Gleam/Kotlin/Clojure/Crystal/TypeScript are all infinitely better, in my experience.

There are so many options now, you just need to explore them and go outside your comfort zone.

If I ever did use Ruby again, I would use Jets over Rails.

Same here.

Though I still do some Ruby. A quick Sinatra proof of concept, some Jekyll hacking or the occasional day of spelunking an old Rails app that suddenly broke for some reason.

But doing most work in Rust, Golang and typescript shows me how much Rails is a pias (but how beautiful Ruby is, and that beauty isn't a great trait for a production programming language)

Why do similar articles or headlines seem to come up at the same time on front page? e.g. there is another article on Rails that happens to be front page right now that is seemingly otherwise unrelated (the other article is called The Rails Cheat Sheet).

I’ve noticed this too sometimes and I think it’s like a “meta” conversation on HN. It happens pretty often and I think people see an article about X, which reminds them of some other good article about X, and then they both end up on the front page because “hey we’re talking about X today!”

Because people love Opinionated Monothlic to "flexible, unopinionated, microservice, cloud native architecture" nowadays.

I used to love Opinionated Monothlic. I still do but I used to too.

I've since moved on to Elixir's Phoenix. Not quite as opinionated as Rails but many of the low stakes decisions have been made.

I used Rails for over 5 years, and both Rails and Ruby were elements that I never had to struggle with to get things done. However, they did have their secrets, and mastering such complex tools can be challenging. I always appreciated DHH's critical attitude, and although I don't like many of Rails' design decisions (such as the use of AR vs. Repositories), I think it solves many typical web development problems out of the box. However, with JavaScript, Kotlin, or Python (to name a few), you have to do all of that manually or they don't measure up.

The thing about building an opinionated framework is that sometimes your opinions suck. I hate using RoR at my job, I curse it every day. How in the hells do you think allowing gems to run their own code without being called is a good thing?

These almost entirely boil down to DHH's personal preferences—which is fair enough as it's his framework—but I don't really see these helping in any general way to understand Rails beyond "whatever DHH wants is his framework".

If you want to understand the core values of Rails they are:

* Implicit behavior through conventions regarding core features like databases and routing * The framework has a reasonable built-in for anything you'd need to make a web app * Major new features or changes usually originate from DHH and 37 Signals

The stated values are mostly useless:

* Programmer happiness - completely subjective as to who is being made happy. Lots of Rails things make lots of people unhappy just as much as the opposite.

* Convention over Configuration - this is the only clearly stated value and it is basically the core ethos of Rails, even though it really means "as compared to J2EE". Rails has a TON of configuration you still need to do on any project.

* The menu is omakase - the text explains better, but the point is that everyone should use the selected tools and yet a good chunk of Rails developers deviate from stuff like minitest, fixtures, etc. That the defaults can be swapped out was never a goal of DHH's and I think they exist only because of the merge with Merb way back when.

* No one paradigm - this is just a retcon for how different parts of rails are different from no really good reason. Why are helpers a big blob of global functions? Why does a controller expose data to the view via instance variables? Why do schema migrations default to nullable fields and no foreign key constraints? Why do you define instance methods on mailers but invoke them as class methods? There's no rhyme or reason to this. It's not bad, but it's also not the result of deeply thinking about the best way to approach these problems.

* Exalt Beautiful code - DHH sets the standard of beauty. This is possibly the worst part of the doctrine because when others adopt this it leads to constant infighting about style and other pointless things. If you've ever seen any of Basecamp's code online, I would not personally call it beautiful. As a doctrine for an open-source project this is useless.

* Provide sharp knives - this is a curious one both in text and analogy. What he's saying is that "dangerous" features should be OK because people should be trusted to use them. Fine, I guess, but if you do any home cooking, sharp knives are far more safe than dull knives. And any language feature can be abused. What is very frustrating about Rails is these "sharp knives" tend to be unobservable so it's hard to know what is happening and why.

* Value integrated systems - this is where it is either DHH's lack of experience or just flat out delusion, because Rails provides exactly nothing to help scale a monolithic system to hundreds or thousands of developers and tons of performance requirements. It can be done - look at Shopify and GitHub - but nothing about Rails gives you a leg up on what is required to build a monolithic system. THAT SAID, like configuration over convention, this does demonstrate Rails value in a roundabout way - you get mostly what you need in one package and, unlike the JS ecosystem, don't have to piece it together on your with starter packs and boilerplates

* Progress over stability - Maybe initially this rang true, but Rails has been extremely stable for a long time, and that's a good thing. The team does a great job of deprecating things and providing an upgrade path, and Rails happy path features very rarely break between versions. But what progress has Rails made at a high level? It still works more or less as it did when it came out. This is totally fine and should be heavily promoted as an alternative to the constant change, rot, and churn in the JS ecosystem.

* Push up a big tent - this is almost entirely untrue. DHH does not value this. Maybe he did when this was written, but he does not value diversity on any real level, at least not based on his written words and public actions. This includes "diversity of thought" as well as "diversity of people".

The Doctrine is a nice idea, but I don't see how it helps anyone really understand Rails beyond "DHH's framework". And again, that's fine. It's his framework. He doesn't have to explain himself and, to be honest, I kinda wish he wouldn't.

revisionism is a dangerous endeavor. react is vastly more popular than rails but doesn’t exalt any of these so-called bedrock of rails’ popularity and longevity. rails appeared at the right time and commented itself as the go-to framework for web development. it enjoyed a monopoly of the worse-is-better crowd’s time and energy. it had a curious coincidence with agile manifesto and the surge for software-as-a-service business. in my opinion, it cemented its place. it’s losing now, to both rails-esque and anti-rails framework but it will be a while until it isn’t among first 3 recommended frameworks for building web/API-based software. the doctrine is largely nonsense.

It cemented itself amidst a whole bunch of web frameworks that didn't achieve its success. If you don't believe that's because of its doctrine you're fooling yourself. When Rails gained not just popularity but great success (as measured in successful businesses launched on it) the back end web development framework market wasn't some uncontested market ripe for the taking. PHP was still picking up speed, Java frameworks were released every semester, Microsoft was packing features into .Net at a steady clip, I think even Django was already well loved in the Python community.

That a framework built on a programming language no one even knew existed would become the most effective web development platform for the better part of the next 5 years was beyond anyone's expectations. It's because Rails was built on consistently good or great decisions, and the only way to be that consistently good is to have a doctrine guiding you.

From the outside it might look quirky, but having a strong opinion on how things should be done specifically for developer productivity and happiness has been a corner stone of the Ruby community since its inception.

you’d be an easy prey to the idea that people can explain their successes and/or attribute it to the one enabler. but you’d be wrong. haphazard systems have won over well-crafted ones when the well-crafted has underestimated the folly of the crowd and its propensity to stick with a bad choice. i submit for your consideration the success and monopoly of javascript. is it because of a yet unpenned doctrine by brendan rich, who, if anything, has only rendered apologies for certain bad decisions.

point is, success doesn’t necessary mean a coherence of thought and practice. especially in rails’ case where we’re talking about its popularity among humans, the most irrational of beings. the crowd elected rails, not for its doctrines. i’m a rails developer and contributor, and none of that arrived by virtue of the doctrine dhh (and by extension, you) espouse.

Reply on news.ycombinator.com