Why We’re Sticking with Ruby on Rails at Gitlab

Re:Why We’re Sticking with Ruby on Rails at Gitlab by Ataraxic on Monday June 13, 2022 @12:21PM (#31727651)

I actually disagree that it's suspicious. I think there are often trends in programming that despite being touted as newer, better, and faster have failed to deliver on that. Ala the amazing amount of churn in JS frameworks in the earlier years of SPA's and such. An article saying y'know what "X is actually good enough" isn't any more suspicious than all the articles saying "Y is the new hot thing".

I am biased here because with respect to the products that I've helped create the speed of ruby vs js, python, etc. has never been a dealbreaker.

Even if porting an entire application wasn't a nightmare, why would you ever do it unless your organization was going to fail without? Porting entire applications needs to be justified by some critical requirement that (in this case) ruby/rails isn't meeting.

https://www.joelonsoftware.com/2000/04/06/things-you-should-... -- Porting an entire application into a new language can easily be a rewrite and not a "port".

[ Parent | on HN ]

Re:Why We’re Sticking with Ruby on Rails at Gitlab by itake on Monday June 13, 2022 @12:56PM (#31728201)

Organizations rarely port working code to new frameworks, but they launch new products and features with new frameworks.

If you're developing and serving ML models, I'd be surprised if they chose to stick with Ruby over Python/Flask.

Gitlab could keep everything "rails" and break out service into micro-rails services.

[ Parent | on HN ]