Live data from Hacker News

Returning to Rails in 2026

markround.com

71–80 of 254 posts

Re: Returning to Rails in 2026

#71
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 ?

Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.

Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.

However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.

The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.

Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.

The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.

Re: Returning to Rails in 2026

#72
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 issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.

Re: Returning to Rails in 2026

#73

Earlier quoted context omitted.

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 ?

Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like…

Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.

It has been absolutely wonderful building this with Elixir/Phoenix. Obviously any codebase in any language can become a tangled mess, but in 7 years we have never felt the language or framework were in our way.

On the contrary: I think Elixir (and Phoenix) have enabled us to build things in a simple and elegant way that would have taken more code, more infrastructure, and more maintenance in other languages/frameworks.

Re: Returning to Rails in 2026

#74
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?

Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.

Re: Returning to Rails in 2026

#75
post #56

Earlier quoted context omitted.

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?

I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?

Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.

Re: Returning to Rails in 2026

#76
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…

I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.

Laravel is extremely stable and consistent.

Re: Returning to Rails in 2026

#77

Earlier quoted context omitted.

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?

Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.

So churn causes more churn.

Also breaking APIs should be regarded very poorly. It isn’t. But it should be.

Re: Returning to Rails in 2026

#79
we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.

Re: Returning to Rails in 2026

#80
post #13

Earlier quoted context omitted.

> what's the difference if my agent uses fucking Next, Nuxt, Rails or Django? The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective". But yes, I do agree that the main line should say what Ruby on Rails actually is, not why it's good for your agent.

doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?

[flagged]
Post reply on HN