Returning To Rails in 2026
39 points by mdr
39 points by mdr
I love Ruby and Rails. I’m a relative latecomer to the stack (~2019), but it’s really been a joy to use.
I come from a Haskell background too! Ruby is great enough that I was fine with abandoning types.
Really the only downside to Rails these days is that DHH got his brain melted on twitter. But luckily, Rails is bigger than just DHH (though it would be nice if he would actually leave).
It was in the back of my mind - should I mention the whole DHH thing ? But I think enough has been written about that already, and I can't really offer anything that hasn't already been said. So I decided to focus solely on the tech side of things - perhaps I should acknowledge the elephant in the room, but that's a bit of a bummer and TBH if I focus too much on things like that it starts to eat away at me and sucks the joy out of the things I do enjoy. Tricky one. Anyway....
Out of interest, what led you to adopting Rails in 2019 ? Was it an inherited code-base or something you were starting from scratch ? Because I'm curious about how much new stuff is actually getting built in Rails these days and there's not a lot of data on that.
Yeah, an understandable decision.
Out of interest, what led you to adopting Rails in 2019 ? Was it an inherited code-base or something you were starting from scratch ? Because I'm curious about how much new stuff is actually getting built in Rails these days and there's not a lot of data on that.
I inherited a codebase (quite a few of them actually). We started out as sort of a hybrid stack team between Dotnet and Rails, but by now, we've not only made a few new codebases in Rails, but we've even started porting Dotnet apps over to Rails.
I was extremely late to Rails and though having used some bigger frameworks I'm historically more of a fan of micro frameworks.
That said after having adopted a Rails framework that originally was meant to be replaced I ended up upgrading it from 4 (or 3) instead and cleaning up the codebase quite a bit while learning the ropes (neither rails nor ruby dev before).
I have to say that I kind of like it. Especially because in the more recent versions the fixed a lot of "sins" (not embracing PG types, 32 bit integers as default IDs, etc.).
I'm a fan of simple solutions because a lot of big frameworks end up being obsolete in one way or another before they worked out their kinks and sharp edges.
I have to say that some things seemingly got fixed/worked on really late. However I'd also say that they have managed to get the abstractions right and did a great job at keeping things very nodular and deciding what should be integrated in core.
It's been a while since I had the opportunity to really dig into a Ruby codebase beyond the odd infrastructure "glue" or ad-hoc reporting things I knock together. I'd forgotten just how much fun Rails is, and how productive you can be with it.
But I did find myself while writing this, why is it that Ruby itself seems to have fallen so much out of favour ? When I was first moving on from Perl it seemed like Ruby and Python were both sort of equally being used for the same sorts of things (I think I first saw Ruby "in the wild" when I used portupgrade on FreeBSD 4/5.x) But I definitely noticed that you could usually rely on the presence of a Python interpreter and Ruby was usually an apt/rpm/pkg install away.
I guess on the Linux side a lot of Red Hat tools seemed to use Python which drove that, and then there was the explosion of data science tooling on Python. But then "Peak Rails" happened before all that as far as I remember, and yet it never seemed to lead to people using Ruby in other spaces outside the web which is big shame. It seems just as natural a fit to processing things the unix-ey way, and in some ways more suited to quick scripting than something like Python which I dunno... feels more "formal".
why is it that Ruby itself seems to have fallen so much out of favour ?
Well, Ruby itself was always a relatively niche language. It was only in the spotlight for a few years because Rails was basically the startup stack from maybe 2007 until 2014 or so. After that, the spot was progressively taken by NodeJS on the basis that you could use a single language on the backend and frontend, and SPAs becoming more or less a baseline requirement. And nowadays, dynamic language without decent support for gradual typing are out of fashion.
But if you ignore Rails, Ruby was never "in favour". You could mention a handful of popular Ruby based projects like chef, puppet, homebrew, metasploit, etc. But they're either niche themselves, or were since then replaced by other projects.
I agree with you that it definitely would have been better suited than Python to be the "modern Perl", and it could have been a really nice niche for it, but that's not what happened unfortunately.
Interesting points. I guess because I found myself in those circles anyway (like Chef & Puppet before everyone seemed to shift to Ansible) and the places I worked at were big Ruby shops around the glory days timeframe, my perception was skewed somewhat. And yeah, I remember NodeJS when that first came out - I was working for a company that did financial modellers and they were really excited that they could use the exact same libraries on the front-end as well as the back end. I just never really liked JS though :/
I do vaguely remember a fair amount of "Ruby is slow" pushback from other teams. And things like JRuby addressing that in some way. I wonder if that perception also had an impact even though we were well into the rapidly increasing core counts and clock speed era at that time.
I wonder if that perception also had an impact
It's likely, but from my perception it wasn't the main factor. "Ruby is slow / Rails doesn't scale" and similar was tooted long before Rails peak popularity, I think it was always well understood what the tradeoff was, and it's not a coincidence Rails was the default startup stack for a while.
Yes execution speed wasn't stellar (It's much better now), but if you are a startup trying to find market fit, only iteration speed and headcount really matter to you.
like Chef & Puppet before everyone seemed to shift to Ansible
Ruby felt like the language of DevOps while that term was basically up and coming. MCollective, Sensu, Chef, Puppet, Vagrant(!), Logstash. I think that a combination of the popularity of Hashicorp products and then Docker and finally of Kubernetes turned Go into the most common language for this stuff, but there was a brief shining moment.
I was never around in the days of Puppet or Chef, but I’ve written enough YAML pretending to be a programming language that I wish a Ruby devops DSL had taken off instead.
Sensu! I'd forgotten that one. The "agents subscribe to a message bus" approach was a pretty radical change back then compared to the Nagios-style polling. I think Go also had the advantage of producing a single binary with no dependencies as the build artifact - I used to maintain a Ruby "devops" tool and having to drag in a Ruby install was always a bit of a drag compared to "just grab this binary and run it"
why is it that Ruby itself seems to have fallen so much out of favour ?
Because, even though it did some things right, it's a really annoying language to deal with in practice. The only grammar is whatever yacc file is checked into the Ruby interpreter repo. Tooling is nightmarish to write, to the point where you have to make sure you import code coverage and unit testing tools in the right order or they choke. The object system's approaches to inheritance (all...what, three of them?) are a mass of interacting sharp edges. If you're treading a super common path in Ruby it's fine, but as soon as you deviate, it's all sharp edges.
I'm curious what your preferred language is. I've enjoyed working in Ruby but I'm also not writing tooling in it. What were you working on that you had these frustrations?
I was writing Splunk's Ruby SDK, so this was a fair number of years ago. I did get to a good place, but it was a very frustrating language. It was an interesting time in some ways because I wrote or was part of the group that wrote the Splunk SDK for a range of languages. The only one more frustrating than Ruby was PHP. Oh, the special things that we learned about PHP...
I don't know that I have a preferred language at this point. I did a lot of Haskell at one point, wrote a lot of Python. Work now is C++, PHP, and TypeScript. I'm mostly writing Clojure outside of work for the little coding I do at home.
But I did find myself while writing this, why is it that Ruby itself seems to have fallen so much out of favour ?
ruby was my preferred language from ~2000-2017, at which point I got a job working in python and developed a deeper understanding of the differences between the two languages. I'm personally convinced that ruby's major flaw is that it does not namespace imports, which means it does not scale as well to large projects as python does. it's still my favourite language for quick scripting but if I had to develop and maintain a larger project I would go with python (or ocaml or rust) every time.
Can you explain the kinds of issues you've had with lacking namespaced imports? My last decade of work experience has been in large Ruby/Rails codebases (100k-1m lines) and I don't know that I've ever run into problems with this.
this is coloured by my background in static analysis tools; I feel like any large dynamic language codebase requires good static analysis tooling to help with maintenance and hardening, and python's namespaced imports make it significantly easier to see where everything is defined.
but even disregarding that and just looking at manually maintaining code in ruby, I have frequently had to grep through the codebase to see where something was defined, and sometimes keep a mental model of all the code generation going on under the hood. the metaprogramming features make it really pleasant to use the language while making it harder to see what is happening when the whole codebase doesn't fit in your head any more.
the metaprogramming features make it really pleasant to use the language while making it harder to see what is happening when the whole codebase doesn't fit in your head any more.
I agree, which is generally why seasoned practitioners of the language eschew overusing metaprogramming. Rails is certainly guilty of using it so much that you have to handwave a lot of behavior away as "Rails magic." Dynamically generating methods saves LOC but is super frustrating to grep for.
I can't remember when I first used Rails, but it must have been around 20 years ago; it looked like an appealing alternative to the Perl CGI pages I was using at the time. Since then it's been very useful. I've been working in scientific research and there's always a need for websites hosting research data and associated tools. These often need changing and Rails is easy to modify, with a good testing framework. The main application I currently support is a Rails API with a Vue client.