4 ms·

I agree with you on all your points but I came to the conclusion that I would _not_ start a new app in Rails for those reasons. I've spent my whole career on R

I agree with you on all your points but I came to the conclusion that I would _not_ start a new app in Rails for those reasons. 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.

codesnik 2y ago
"tech bankruptcy"! this is a VERY strong sentiment. First of all, I've never seen a rails-based company which has it problems from tech department, and not from product market fit or whatever, and that's in a 18 year carreer. I'm singlehandedly refactoring right now a 10-yearish rails app which had a period of neglect and bad contractors who broke every single test, and it is still very much manageable.
- stouset 2y ago
  > I've never seen a rails-based company which has it problems from tech department 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).
  - lcnPylGDnU4H9OF 2y ago
    Hadn't heard of Hyrum's law before. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ 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. (There's something about the way people manage to phrase these that I really enjoy. Something about the succinct and clear expression of an idea that's otherwise really fuzzy in my head.) 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.
- skipants 2y ago
  I agree it's a strong sentiment. But development seems to slow to a crawl at around that time from what I've seen. And then it seems like keeping the app going needs extremely strong developers around it, which not every company can afford. It's just bad value; you have to pay a lot to continue to develop at a normal pace. 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.
dnh44 2y ago
Over a decade ago when Rails was the shiny new thing I wrote an online ordering system that batched received orders then sent out orders to suppliers for whatever the customers ordered. It was easy enough to get the app setup and it didn't often need any new features but I remember really struggling to get it up to date and working with each new rails version. My memory is clouded by both time and my inexperience at the time but even though the app was "done" it never actually felt finished because I felt the need to continually update to the new version of rails just in case I did want to take advantage of of the new features in newer versions rails. 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!
- cutler 2y ago
  Isn't the conclusion of this aticle that it's a bad idea, ie. Rust API?
  - dnh44 2y ago
    I guess my post wasn't a critique of the blog post, it was a somewhat related story. I do actually agree with the blog post about not rewriting something that works. In my case it's a totally new project but it was my previous experience with Rails that made me not want to try it again for this particular project. 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.
RangerScience 2y ago
Rails, ironically, doesn’t keep you in the rails. I’ve seen a couple of the things you’re talking about, and it’s really just mediocre devs in bad (but common) situations. If someone gives you a paint-by my-numbers page, and you just scrawl all over it… is that the “fault” of the page?
wkirby 2y ago
I think the context here is super important: I run an agency, and a lot of our clients are small startups or solopreneurs. The most important factors in determining their tech stack are (in some order): * 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.

codesnik 2y ago

"tech bankruptcy"! this is a VERY strong sentiment. First of all, I've never seen a rails-based company which has it problems from tech department, and not from product market fit or whatever, and that's in a 18 year carreer. I'm singlehandedly refactoring right now a 10-yearish rails app which had a period of neglect and bad contractors who broke every single test, and it is still very much manageable.

stouset 2y ago
> I've never seen a rails-based company which has it problems from tech department 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).
- lcnPylGDnU4H9OF 2y ago
  Hadn't heard of Hyrum's law before. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ 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. (There's something about the way people manage to phrase these that I really enjoy. Something about the succinct and clear expression of an idea that's otherwise really fuzzy in my head.) 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.
skipants 2y ago
I agree it's a strong sentiment. But development seems to slow to a crawl at around that time from what I've seen. And then it seems like keeping the app going needs extremely strong developers around it, which not every company can afford. It's just bad value; you have to pay a lot to continue to develop at a normal pace. 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.

dnh44 2y ago

Over a decade ago when Rails was the shiny new thing I wrote an online ordering system that batched received orders then sent out orders to suppliers for whatever the customers ordered. It was easy enough to get the app setup and it didn't often need any new features but I remember really struggling to get it up to date and working with each new rails version. My memory is clouded by both time and my inexperience at the time but even though the app was "done" it never actually felt finished because I felt the need to continually update to the new version of rails just in case I did want to take advantage of of the new features in newer versions rails. 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!

cutler 2y ago
Isn't the conclusion of this aticle that it's a bad idea, ie. Rust API?
- dnh44 2y ago
  I guess my post wasn't a critique of the blog post, it was a somewhat related story. I do actually agree with the blog post about not rewriting something that works. In my case it's a totally new project but it was my previous experience with Rails that made me not want to try it again for this particular project. 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.

RangerScience 2y ago

Rails, ironically, doesn’t keep you in the rails. I’ve seen a couple of the things you’re talking about, and it’s really just mediocre devs in bad (but common) situations. If someone gives you a paint-by my-numbers page, and you just scrawl all over it… is that the “fault” of the page?

wkirby 2y ago

I think the context here is super important: I run an agency, and a lot of our clients are small startups or solopreneurs. The most important factors in determining their tech stack are (in some order): * 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.