I've spent my whole career on Rails and I think it's amazing when starting small but mature applications are a nightmare to refactor. Every monolith Rails app feels like it hits tech bankruptcy after ~5 years.
I've been using Rails since 1.0, owe much of my career to it, and still think it's an incredible framework that I love using.
But I have seen plenty of startups—mostly filled with junior developers—who don't have the maturity and experience to avoid some really bad ideas absolutely wall themselves into a corner. Thankfully the worst of this was in the Ruby 1.8 and Rails 2.3 era, but it still happens today.
A lot of the issue is the tendency that Ruby libraries have toward exposing internal details that end up getting relied upon (Hyrum's law in action).
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
It's interesting to think about the implementation being necessarily coupled with the interface. In some context that's obvious, but the idea that another implementation can't be freely swapped in -- because nuanced behavior (sometimes called a bug) in the original implementation is still expected -- is one I hadn't, as such, thought much about before.
I think the fact that we are trying to shove typing onto Ruby with Sorbet and RBS are a sign that maybe it's not the best programming language once you reach critical mass.
It's possible the grass is greener and this is what happens to every tech department... but I'm not totally convinced. I always hit a point with Rails apps where I can see the refactorings I'd like to make but I know it's not worth the pain of the inevitable `NoMethodError` at run-time in production. And that's _with_ a giant test suite.
* Time from idea to deployed solution * Ease of pivot * Ease of finding other devs who can take over
If I were a staff engineer at a large company with an existing tech stack tasked with spinning up some new internal microservice, I'm probably not choosing Rails.
But if I'm truly greenfield on a strict budget, still searching for product market fit? If that application ever truly outgrows rails (and it can become wildly successful without doing so --- look at stripe, instacart, github, shopify) then we've already won by surviving long enough for rails to be the problem.
Anyway over 10 years later now and I find myself writing an API and my initial thinking was to return to rails but then I remembered the bad experience (which was probably my own fault I acknowledge).
Now I find myself writing this API in Rust because the ethos that an app can actually be done is attractive to me. It's taking me longer to write but hopefully I've made a good decision!
The API I'm working on is pretty simple and I want to finish it and forget about it so in my circumstances it seems that rust is a better choice.
If someone gives you a paint-by my-numbers page, and you just scrawl all over it… is that the “fault” of the page?