Live data from Hacker News

Returning to Rails in 2026

markround.com

241–250 of 254 posts

Re: Returning to Rails in 2026

#241

Earlier quoted context omitted.

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…

It's really hard to get away from ssjs frameworks for front-end, so for my startup it's Axum + Seaorm for "the api" and a Svelte SSR "front end" / view layer.

I think rust programers are more likely to want flask/rack than Django/rails.

Re: Returning to Rails in 2026

#243

Thanks for such public confirming there is a lot of more us. I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures. I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Si…

You are absolutely not alone, brother (or sister). In the past few years when a lot of the millennial generation started getting their first jobs, the shiny object syndrome took over and most everything being made now is a distributed monolith pile of spaghetti code trash.

There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.

Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.

Re: Returning to Rails in 2026

#244
post #209

Earlier quoted context omitted.

I worked with Rails a lot. In my experience, every rails dev who is fanatical about how much they love Rails, also has little to no experience with strong types. Of the ones who later try types, they no longer love Rails. Personally I quit Rails entirely because of lack of types. No, RBS and Sorbet are not even close to good enough. Also, every enterprise rails app I've seen (seven, to date) has been really poorly wr…

I still really like rails. It’s really fun until your codebase reaches a certain size. At that point you better have a large suite of test which becomes a problem of it self because the tests will take forever to complete. I tried sorbet a couple of times and totally get why it’s useful but imo it’s not just lacking (e.g. compared with what can be done with TS or even a simple type system like golang) but it also rem…

Right, the test culture is very silly to me. Thousands of tests and long CI times, basically just doing a poor invention of a compiler. Dynamic types are so much extra work.

Re: Returning to Rails in 2026

#245
post #198

Earlier quoted context omitted.

> Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. All right, fine: TypeScript uses structural typing which is if you like a specialisation of duck typing but, whatever, compared with JS's unadorned duck typing it still leads to embellishment of the resulting code in ways that I don't enjoy. I've been using TypeScript across different projects at different compa…

I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easi…

> the problems it did flag mostly would be caught by minimal testing

Yeah, I agree, and the thing is, you're going to write automated tests whether you're developing in JavaScript or TypeScript so the extra cruft of TypeScript seems even less worthwhile.

The argument I've heard people put forward is that JS is fine for small projects or a couple of developers but doesn't scale to large projects or teams. I don't know how large large is, but I've worked on a project with around 30 devs where the front-end was all JavaScript and everyone was touching it and, sure, that project had some problems, but the root cause of those problems wasn't using JavaScript.

Re: Returning to Rails in 2026

#246
post #231
post #198

Earlier quoted context omitted.

I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easi…

> the problems it did flag mostly would be caught by minimal testing Testing is more expensive up front and in maintenance than type annotations. A test suite comprehensive enough to replace type annotations would have an ass load of assertions that just asserted variable type; if you were involved in early pre-TS Node, you remember those test suites and how they basically made code immutable. > (2) it regularly miss…

> here are a lot of unsafe edges to TS

And one of its many problems is that it tries quite hard to pass itself off as not having those unsafe edges which, ironically, makes it easier to get tripped up by them.

Re: Returning to Rails in 2026

#247
post #111

We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it). The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked…

We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains. In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js. It's amazing…

I'm availabe! On rails for over 21 years since version zero. It's strange, but true, that we Rails-devs are hard to find. I apply for Rails-related roles and am competing with over 1,000 other resumes. I'm not sure how I fail to even get a screening call 99% of the time. Perhaps overqualified? Perhaps poor filtering? It is a very strange job market.

Re: Returning to Rails in 2026

#248

Earlier quoted context omitted.

I'm confused. It's too much work to upgrade dependencies, but not too much time to write from scratch and maintain, in perpetuity, original code?

Yes. I've probably spent more time maintaining a trivial Rails app originally written in 2007 than I spent writing it in the first place.

But if you would have rewritten the entire app every time you needed to update the dependencies, that would have taken even more time.

Re: Returning to Rails in 2026

#249
post #2

The main line on the Rails website now reads: > Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review And I fucking hate it. If I read this the first time I would think this is some kind of tool to optimize your LLM agents. I have been using Rails for over a decade now and always liked…

I haven't found anyone pushing back on it at all, which has been making me a bit nervous! There was a HN post about it, though it didn't get any traction. [0] Seemingly nothing in any of the usual rails community areas either. It's going to make recommending rails confusing because that pitch really does make it unclear what rails is even aiming to do.

And yeah you're right, like what is the difference at that point? If the pitch is "AI agents write this", then the obvious response is "well why would I not use what has more training data then?".

[0] https://news.ycombinator.com/item?id=47272953

Re: Returning to Rails in 2026

#250

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…

Is this still a valid take after the study that came out,showing how Ruby performs way better with agentic coding?
Post reply on HN