Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Returning to Rails in 2026

markround.com

Post reply on HN
Print view View original

131–140 of 254 posts

Re: Returning to Rails in 2026

#131

Post by __mharrison__ »

f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

Use UV for dep management. Make sure you have tests.

In the past month I migrated a 20 year old Python project (2.6, using the pylons library) to modern Python in 2 days. Runs 40-80 times faster too.

Re: Returning to Rails in 2026

#132

Post by stevepike »

vintagedave wrote: post #39
f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

Sometimes I think the issue here is churn . Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?

The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.

One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.

Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.

(I run a startup that's a software-enabled service to upgrade old Rails apps).

Re: Returning to Rails in 2026

#133

Post by fnoef »

I’m honestly baffled by the praises of Rails in the comments.

I started my dev career with php and then nodejs, but recently got a job with rails, and honestly, it’s the worst among the 3.

There is no static typing whatsoever, it’s littered with magically generated methods, on a moderate size project the controllers or models directories grow to dozen of files. In general it feels like you need a lot of mental context in order to work with Rails, and I believe this is the reason people who run it for 10+ years in production love it. They simply carry all the magic in their heads, rather than let the framework guide you.

I, however, get much more DX and production stability by building with a boring (router + server side rendering) NodeJS stack with typescript and schema validation. My services are more stable and do not crash on “undefined method foo for nil”.

I guess people will defend whatever they know best, even if it has quirks.

On a positive note, I like ruby as a language. It has cool features like pattern matching, named arguments, or dropping verbose statements like “return” at the end of the function.

Re: Returning to Rails in 2026

#135

Post by miguno »

louiskottmann wrote: post #35

I've been a Rails DevOps and nowadays a web one-man-show with it for over 10 years and I'd do it again. Not many frameworks have been thriving that long, and there's good reason. It packs everything, is tidy and productive, with a pleasant language to read and write. In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception ! Give it a try…

> In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception !

Oh, where did you find that?

Only info I could find was that Rails is at rank 10 in the Web Frameworks category for Admired vs. Desired in the 2025 survey: https://survey.stackoverflow.co/2025/technology/#2-web-frame....

Re: Returning to Rails in 2026

#136

Post by cpursley »

mark_round wrote: post #63
bronlund wrote: post #7

I've never used Rails, but I agree upon "the state of the modern landscape". Instead of looking backwards, I tried to look forward, and what I found was Elixir and the Phoenix framework.

You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!) Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?

I've put together a number of resources here: https://elixirisallyouneed.dev

Re: Returning to Rails in 2026

#137

Post by the__alchemist »

paride5745 wrote: post #122
sensanaty wrote: post #110

I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project. Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is…

Rust/Loco is unironically the most interesting framework right now. Loco follows up the Rails formula pretty closely, and makes easier to learn Rust by taking care of a load of boilerplate code.

Concur on most interesting! I really hope it works out, but am cautious.

It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this about how people are using these tools. I.e. even though rust is my favorite overall language and see no reason it couldn't be used for web work, I still use Django.

Axos, Axum, Rocket, Diesel etc, are all IMO not in the same league as Django. My understanding is that addressing this is Loco's Raison d'etre.

Another aspect of the Rust web ecosystem: It's almost fully gone Async.

Re: Returning to Rails in 2026

#138

Post by wutwutwat »

draw_down wrote: post #116
sensanaty wrote: post #110

I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project. Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is…

I’ve worked in two places now with Ruby Sorbet servers. Ruby always drives me nuts how things are just in-scope and we don’t know why or where they came from. I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now. I would say Sorbet seems more “basic” than something like Typescript. It handles function calls matching signa…

> I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.

> and at times you’re fighting to convince it that a value actually is the type you say it is.

Might just be allocating that brain power to the same task but calling it a different thing.

Re: Returning to Rails in 2026

#139

Post by paozac »

e12e wrote: post #105
paozac wrote: post #10

I love rails and the recent improvements are great. I have the impression, though, that these days it only appeals to those who picked it up before version 3 or 4, when it was smaller, maybe more understandable, and incredibly better than all the competing frameworks (except Django maybe). If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might…

I'd say that if you're first encounter with rails is version 8+ -- it's a lot easier to use than previous versions. Partly because the handling of JavaScript is much less bespoke and complex.

Javascript handling in Rails was easy in the early versions, then became messy with the asset pipeline and webpacker, and is becoming simple again with the latest versions

Re: Returning to Rails in 2026

#140

Post by le-mark »

satvikpendem wrote: post #127
kshahkshah wrote: post #115

Earlier quoted context omitted.

Are you hand coding?

Doesn't matter because LLMs also benefit greatly from typed code bases in that they can run the type checker and fix the problems themselves on a loop.

I haven’t seen much discussion about this point other than “llm handle languages x y and z because there’s a lot of training data”. Watching Terence Tau using llm for writing proofs in Lean was a real eye opener in this regard.
Post reply on HN