9 ms·

Returning to Rails in 2026

373 points by stanislavb 7mo ago

shafyy 7mo ago
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 the focus on writing beautiful and simple code. On making it easy to reason about with colleagues. Now it seems like DHH is throwing all what made Rails special overboard. If we are all supposed to be talking to agents now, what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
- hamandcheese 7mo ago
  > 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.
  - gfody 7mo ago
    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?
    - vidarh 7mo ago
      The frontier models all handle Ruby just fine. So does th cheap Chinese models like Mini, Qwen, Deepseek.
    - barrkel 7mo ago
      Claude munches through Ruby just fine, all day long.
    - hrmtst93837 7mo ago
      [flagged]
  - fy20 7mo ago
    There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well. However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
    - gommm 7mo ago
      Personally I love rust for agents because of types. In the ruby world there's sorbet and rbs so would be interesting to try that.
    - Kerrick 7mo ago
      Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
    - apsurd 7mo ago
      TS is very AI native to the point i'd agree it's near magical in terms of contract. However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy. For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything. you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
      - sodic 7mo ago
        > TS is very AI-native, to the point I'd agree it's near magical in terms of contracts. I agree. Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot. Looking at other candidates: - Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability. - Go is much more usable and very popular, but its type system can't communicate much. - Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity). - etc. I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out. And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
  - operatingthetan 7mo ago
    >The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective". The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
- quinnjh 7mo ago
  >If we are all supposed to be talking to agents now, what's the difference[...]? it's a little cringe, but arguably the benefit of having agents use rails would be tht when you review and audit the agent produced code, you review something that is, as you put it: "beautiful and simple code" and "making it easy to reason about..." I loved rails back in 2017. I may be an outlier but the line tempts me to try it again despite having adopted the who cares attitude to langs. Would be nice to hear from someone first hand if they felt it helped.
- Zanfa 7mo ago
  > 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 This is so painful... I can't help but wonder who they're trying to target with such inane slogans. Rails is amazing, but "token-efficiency" is not on the list of reasons why.
  - stephenr 7mo ago
    > This is so painful... I can't help but wonder who they're trying to target with such inane slogans. The people who think that spicy autocomplete actually has an understanding of the slop it's churning out for them.
    - Zanfa 7mo ago
      Those people don't choose frameworks. It'll be chosen for them by some LLM and given the prevalence of JS, it'll likely be some flavor of React.
  - wiseowise 7mo ago
    > This is so painful... I can't help but wonder who they're trying to target with such inane slogans. Typical DHH insanity.
- kubafu 7mo ago
  I thought you were joking so I went to check it myself and... unfortunately you were not. That is insane.
- slopinthebag 7mo ago
  Oh boy. I can't even imagine what sort of hell an AI could unleash on a language as dynamic and magical as Ruby...
- raincole 7mo ago
  Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
- mark_round 7mo ago
  Author of the article here (hi! Anxiously watching my Grafana stack right now...) I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM. [1]=Well, I had a stronger response initially but I toned it down a bit for here...
- apsurd 7mo ago
  both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge. fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
- imafish 7mo ago
  That is just DHH (/37signals) being expert(s) at positioning. Trying to answer the question of, why is language and framework still relevant in a world where almost everyone uses an agent for coding?
- graypegg 7mo ago
  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 https://news.ycombinator.com/item?id=47272953
ramon156 7mo ago
I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what. I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom. Just to note, its a really boring app thats been done before (odeva.app)
- kugelblitz 7mo ago
  I usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend. I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around. I think the challenge is to keep working on your old legacy projects. Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
  - ramon156 7mo ago
    I totally agree. At my first job, they instantly jumped towards Symfony and AngularJS. Sounds good, but they could've totally gone for something more lightweight. They DID NOT NEED the complexity AngularJS (and Angular2) brought them. When I left I tried my best to update to at least an LTS version, but I did not succeed and they did not care. I believe they're now migrated to Angular2 but are already stuck in hell
bronlund 7mo ago
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.
- mark_round 7mo ago
  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 ?
  - licorices 7mo ago
    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 you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got. Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir. Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
    - marceldegraaf 7mo ago
      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.
paozac 7mo ago
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 actually strongly dislike it
- XYen0n 7mo ago
  I now also believe that at least Active Record is much easier to use than Django's ORM
  - rdevilla 7mo ago
    Doesn't matter when devs just slop out 400 lines of SQL and bypass the ORM. Frameworks and structure will save you from neither stupidity nor ignorance.
    - dewey 7mo ago
      That has always been the case, why would it be different now? Easy to flag and spot in code review.
      - rdevilla 7mo ago
        Boy, I sure wish I had the opportunity to review codebases before inheriting them for maintenance...
        dewey 7mo ago
        I get your point but this is neither a Rails, nor an AI problem and as old as time.
    - _kblcuk_ 7mo ago
      I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
neya 7mo ago
One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework. However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them. Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.
- slopinthebag 7mo ago
  Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
  - apsurd 7mo ago
    it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine. that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages. edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever. i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
    - slopinthebag 7mo ago
      I don't get your point, I'm not saying sanitising user input isn't important, I'm saying these JS frameworks are only concerned with server rendering and routing. They don't provide any tooling for databases like Rails or Laravel do.
ssaunier_ 7mo ago
Article nicely written, great overview of Rails current state. Kudos to the author.
dewey 7mo ago
Great post, this has also been my experience in the past 2 years. Rails is just a lot of fun, and that’s especially important for side projects. I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.
pjmlp 7mo ago
Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore". As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive. Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.
- wiseowise 7mo ago
  > As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive. Not until they get their gradual typing story straight.
  - pjmlp 7mo ago
    Depends on how much one likes the Smalltalk, SELF or Lisp development experience, regarding types.
louiskottmann 7mo ago
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.
- axelthegerman 7mo ago
  And most folks getting stuff done with Rails ain't be filling out surveys to boost their stack - or maybe that's just me. So everyone just stop worrying what everyone else thinks or seems to think and just use the right tools for you and get on with it
  - wiseowise 7mo ago
    There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
    - psychoslave 7mo ago
      There are two types of dichotomy: those which are autoreferring and sound, those which are absurd, and those which are really going too far.
- fpauser 7mo ago
  rails = ruby = oo/mutable && slow && resource hungry
  - techpression 7mo ago
    And for a lot of folks that just doesn’t matter. Paying 50 or 100 USD for a server per month won’t be the thing that breaks you. Before you get to a scale where Rails become a problem you need to have a product that drives a pretty significant engagement, that’s where most fail.
misiek08 7mo ago
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. Sit down, write minimal (in case of PHP not so cool looking) code and proceed to next task.
- bartread 7mo ago
  I've just started using RoR for a live greenfield project since New Year. Honestly, breath of fresh air. It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso than the ones I've listed, which are the ones I used), only it's web development. For me web development has always felt like a frustrating ordeal of keeping track of 10,000 moving parts that add noise and cognitive load and distract you from fixing the actual problems you're interested in solving. This means the baseline ancillary workload is always frustratingly high. I.e., there's too much yak-shaving. Whereas Rails seems to drag that all the way down to a level where it feels more similar to the minimal yak-shaving needed to (at least superficially) build, run, and distribute desktop software. Not that this is without its challenges, because every deployment environment is a little different in the desktop world, but the day to day developer experience is much lower friction that modern web development in general. Also, no sodding TypeScript to deal with. I hate TypeScript: an ugly, verbose, boilerplatey abomination that takes one of the nicest and most fun features of JavaScript (duck typing) and simply bins it off. Awful.
  - oorza 7mo ago
    TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.
f311a 7mo ago
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 would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.
- vintagedave 7mo ago
  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?
  - ch4s3 7mo ago
    Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.
  - jmusall 7mo ago
    I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
  - comboy 7mo ago
    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?
    - vintagedave 7mo ago
      Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.
dalemhurley 7mo ago
Ruby on Rails and Laravel all the way. Solid, proven, stable and scalable.
zhisme 7mo ago
it is also very token efficient in nowadays modern AI driven development[^1]. I wish more people would renown ruby/rails [^1]: https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-file#total-time-and-cost-v1--v2 https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-f...
mergeshield 7mo ago
[flagged]
- chrisweekly 7mo ago
  Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
- matheus-rr 7mo ago
  This is the thing people who haven't run a Rails app for years don't appreciate. I went through the Next.js pages router to app router migration on a production app. That wasn't a version bump, it was a rewrite across a different mental model. Rails upgrades are painful but the path is documented, the deprecation cycle gives you a full minor version to fix warnings before they become errors, and the team usually knows where the sharp edges are. The Ruby version management story is actually solid too. rbenv/asdf pin files make it hard to accidentally run the wrong Ruby version, which removes a whole class of environment drift issues you don't even realize you have until you've fixed them.
shanjai_raj7 7mo ago
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.
- chrisweekly 7mo ago
  nextjs pages -> app router is a massive change: new paradigm, practically replatforming.
  - shanjai_raj7 7mo ago
    yes exactly. we had to rewrite most of our data fetching logic. there was no real way to do it gradually, one day we just had to commit and do the whole thing. took way longer than expected.
midnight_eclair 7mo ago
i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs
nick_lt 7mo ago
[dead]
dzonga 7mo ago
Rails for straight up CRUD is top, autogenerated things etc however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
- peepee1982 7mo ago
  Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD? I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth. But now, I use AI for scaffolding, and for my side-projects often never have to touch code. So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI? I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
- rco8786 7mo ago
  FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries. I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
- dmix 7mo ago
  If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node. Go and Rust fill in lots of gaps for more serious performance stuff.
andrewstuart 7mo ago
Remember only one programming language delivers developer joy - Ruby. No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.
livando 7mo ago
I used to think ruby/rails was the best way to solve most problems, I still do, but I used to too.
neomindryan 7mo ago
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 at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making. Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
- pqdbr 7mo ago
  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 how powerful this stack is and how little you have to change in the backend.
  - sodapopcan 7mo ago
    I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)
    - shevy-java 7mo ago
      > Maybe not? Because there are fewer and fewer ruby/rails people available. It is the simplest explanation - and the one that makes the most sense, too.
sensanaty 7mo ago
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 these days, though, especially the RoR experience
- mattsears 7mo ago
  What is it about large untyped codebases that make it a nightmare?
  - fourseventy 7mo ago
    If you make a change to the return types of a function for example you have to manually find all of the different references to that function and fix the code to handle the change. Since there are no compile time errors it's hard to know that you got everything and haven't just caused a bug.
    - stouset 7mo ago
      Especially with duck-typing, you might also assume that a function that previously returned true-false will work if it now returns a String or nil. Semantically they’re similar, but String conveys more information (did something, here’s details vs did(n’t) do something). But if someone is actually relying on literal true/false instead of truthiness, you now have a bug. I say this as a Ruby evangelist and apologist, who deeply loves the language and who’s used it professionally and still uses it for virtually all of my personal projects.
    - Salgat 7mo ago
      The best perspective I've seen is that statically typed enforcement is basically a unit test done at compile time.
      - 7mo ago
ClaudeAgent_WK 7mo ago
[flagged]
fnoef 7mo ago
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.
- bovermyer 7mo ago
  If you like Ruby but don't like Rails, take a look at Crystal, possibly with the Amber framework.
devnotes77 7mo ago
[flagged]
sriramgonella 7mo ago
[flagged]
- catlover76 7mo ago
  [dead]
- gf263 7mo ago
  LLM comment Edit: don’t agree? Look at the page!
  - deleted 7mo ago
    [deleted]
- coreyburnsdev 7mo ago
  is this really relevant anymore now that AI has gotten to the level it has? what used to take weeks to setup now take days (react, multiple backend services and infra)
  - CodingJeebus 7mo ago
    Very relevant, because it typically takes a lot less code to express a feature in Rails/Hotwire than it does in a SPA with a dedicated back end. No need to maintain API contracts or ensure your UI code is properly async/awaited, etc., etc. Whether its a human or AI writing the code, SPA's add considerable complexity that just isn't necessary for most web apps. Lower LOC to express a feature means better context management which pays dividends for things like code review.
- morpheuskafka 7mo ago
  This "feels like" first sentence / "curious if" ending question patterns seems to be coming from some LLM? I have seen the same across several online communities suddenly and frequently as of a few weeks ago. Notably the use of "I've seen" and "feels like" suggest the model is either prompted to act as a person or is one of the older models not strongly trained not to.
itsthecourier 7mo ago
try ActiveAdmin, it reduces work a lot. also, ruby is so succinct and rails is so opinionated, Opus is super effective building code and keeping the codebase well structured by default
shevy-java 7mo ago
> Rails seems to have pretty much fallen out of favour, coming in at #20 underneath the bulk of top-10 JavaScript and ASP.NET frameworks It's not just Rails. Ruby is dying. And has been for quite some years now. The strangest things are people writing blog entries claiming the opposite. Like "ruby ages like fine wine". No, that is incorrect - it is dying. I have been using Ruby since about 2004 or 2005. I still use it just about daily. I started before Rails and couldn't care any less about Rails; sadly the ecosystem is infiltrated by corporations such as shopify and others. You can see how they took over RubyCentral effectively (and if they insinuate otherwise - nope, I am not an idiot. I see the pattern. I notice what is happening. You call a black cat a green frog and I call bullshit. It's a black cat. See RubyCentral running amok already before they mass-purged developers, but that's another story - let's go back to ruby, and rails.) > And Ruby itself is nowhere near the top 10 languages, sitting just underneath Lua and freaking Assembly language in terms of popularity! Yup. Ruby is dying. It is following perl. Now, defining "dying" is hard because you still have an active community, even outside of the train wrek that is rails (anyone still caring what random crap DHH writes on his blog? I've noticed fewer people care about the garbage he publishes, other than making fun when shopify damages the ecosystem - oh wait, he sits on the board of shopify. Did I already point out how much damage shopify causes here?). > But I’m a stubborn bastard, and if I find a technology I like, I’ll stick with it particularly for projects where I don’t have to care about what anyone else is using or what the latest trend is. On this part I agree. Ruby as a language is very well designed. It is a great language. I don't think anyone really objects to this, so the criticism has to be split - some criticism is valid, some is not. As a language ruby is well designed. Nonetheless it is dying too. That is also a factual statement. Anyone claiming the opposite is wrong. At the least this is the case right now, and has been in the last some years, to varying extent. > realised Ruby was “a better Perl than Perl”. Also true. Ruby is the better perl. But I actually call Ruby syntactic sugar over C, because this is actually what Ruby is, if you think it through. My use cases are mostly helper-scripts, tons of that, over whatever I do in general. Literally everything computer-related. That includes use cases for the world wide web. All my needs here are covered by Ruby - but not by rails. I don't need rails. Sadly, ruby also has a second problem: documentation. The documentation is crap in general. Look at rack. Opal. WebAssembly for Ruby. That documentation is a joke. An insult. Even sinatra, though better documented than these, has a bad documentation for the most part. There are some exceptions; for instance, hexapdf is well documented, and Jeremy's projects are also well-documented. So I am not saying everything is poorly documented. But for a language that once claimed it wants to compete against python ... sorry, documentation-wise this is still an epic failure point. In some ways ruby actually deserves to follow the path to extinction like perl did, merely because it failed to adjust, adapt and really improve. Yes, there is some internal improvement, but in many ways ruby failed to solve the problems people critisized it for, for many years. And now catching up is SUPER hard. I don't think it can happen anymore. I thought it was possible 10 years ago, but the last 5 years made it clear that ruby is towards extinction. It still does not change me using it, since ruby covers my use cases, but anyone thinking there will be an influx of new young folk driving ruby forward, is just worshipping an illusion here. > There’s just this minimal translation required between what I’m thinking and what I type. That's true. Ruby is kind of transitioning your thoughts into code. > Sure, I can knock things together in Python, Go, or whatever the flavour of the month is, but I always feel on some level like I’m fighting the language rather than working with it. Kind of, though python works fairly well too. > And of course there was the welcoming, quirky “outsider” community feel with characters like Why the Lucky Stiff and their legendary Poignant Guide To Ruby. Well - _why ragequit when someone doxxed him. But even aside from this, I found the poignant guide super-confusing. It was art, but I prefer less confusion myself. Still, _why is gone from the ruby ecosystem. Supposedly he is still doing computer-related stuff in reallife but he is no longer really affiliated with ruby as such. Did I already point out that ruby is dying? > it’s just so nice being able to write things like unless date <= 3.days.from_now I don't doubt that rails is useful, but code like that sucks. Rails also came up with HashWithIndifferentAccess. This simply shows a lack of UNDERSTANDING. They pushed the DSL madness way too far. Yes, I get it, "I don't want to care if we have a string or a symbol" - easier access. But it is the wrong THOUGHT process here. And just the name itself ... HashWithIndifferentAccess versus Hash. Sorry rails guys - you were not good designers in a general sense of the word. The DSL may work; the DSL may be useful, but language or API designers? Nope, sorry. It's awful. if upload_size > 2.megabytes I don't like this either, but I have less reservation here than compared to using numbers for time/date. It's cool that ruby is flexible to allow this, but I still think it is the wrong THOUGHT process.
leke 7mo ago
Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.
- gls2ro 7mo ago
  Is is the need for static types or the need for better testing that is not focused on coverage of line of code? Because if the domain logic is getting more complex then more types will not catch the bugs unless you are willing for codify business rules within types so then you have to test the types.
itsthecourier 7mo ago
and security. ideally a JS frontend app won't show logic not intended for the user type in question. in practice, really often I see a huge app covering all roles and cases, a trove of info for the red team. and even worse, the reality of software development with LLMs in 2026 is plenty of code is being shipped without security audit. I know it's not an inherent fault of the JS frameworks. bit I share what I see on the streets, most of custom JS apps I see are way more vulnerable to hacking than a old-style MVC app. yes it is possible to make mistakes in both styles, but in JS apps I probably see 400% more easily discovered vulnerabilities than in a common MVC (even with stimulus) app
lowenbjer 7mo ago
I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time. I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty. What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem. Also: God i miss writing Ruby, its a fantastically and beautiful language. Also: Blast from the past: Ruby is a great DSL for Rails.
- blandflakes 7mo ago
  > I pick tools by the problem, not loyalty. Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though). What did you move onto for those next things you started building?
  - lowenbjer 7mo ago
    I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's mostly TypeScript, Go, and Lua.
    - blandflakes 7mo ago
      Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.
systems_glitch 7mo ago
Nothing wrong with Rails in 2026. We still use it for both internal and customer projects. I haven't yet encountered anything that made me feel like switching. I'm also not interested in changing frameworks just to have the New Hotness die in 2-5 years (our oldest currently maintained Rails project is over 10 years old, and some stuff I started working on when Rails 2 was new is still being maintained, just not by us)
butterlesstoast 7mo ago
> sometimes it’s worth doing things just for the sheer hell of it.
desireco42 7mo ago
I always enjoyed Rails, it isn't perfect but is way better then others. I have node and nextjs projects :) when they blow it, it is a major mystery what is blowing up. Have so many good memories working with Ruby. If anyone has old codebase need to be updated and upgraded, refreshed. I am happy to do that.
pier25 7mo ago
I spent 2024 and 2025 trying all the big fullstack monolithic frameworks (Laravel, Rails, .NET, Django). There are differences of course but they all suck so much for doing frontend. In part because for a modern frontend dx you will need hot reload, bundling, etc. But even if you make an SPA and only use eg .NET for an API, using something like OpenAPI to share the schema is a subpar solution. There's really nothing as good as sharing TS types across your whole app(s).
ricardorivaldo 7mo ago
just don't
fixxation92 7mo ago
"I have a tendency to go down rabbit holes when faced with problems - give me a minor inconvenience and I’ll happily spend weeks building something far more elaborate than the situation warrants." You don't know how happy I was to read this... I thought I had a serious problem with getting distracted with my "projects" but it seems this is much more normal than I thought ;-)
deleted 7mo ago
[deleted]
ergocoder 7mo ago
I unfortunately don't want to work on an untyped codebase anymore. It's been 20 years, and Ruby/Rails still can't get their typing working.
tianrking 7mo ago
[flagged]
yazantapuz 7mo ago
Ohmygod. Reading all that blog posts about RoR in Google Reader and is the old fashioned way now?
liamgriffiths 7mo ago
To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/ https://sorbet.org/ Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type system for writing and understanding conventional software. I'm rooting for further developments in this space because I love language and systems that can leverage it's strengths and layering on a type system makes it a very formidable technology for building real world products. I have not used Rails in a few years, but I can also say that the Sorbet typing support for the framework is definitely there too -- to great credit to the folks at Shopify allowing users of the framework to benefit from this tooling. I would happily work on a Rails system today too. It's an amazing testament to the community how the design has been able to continue to develop to meet the needs of the many developers building with it up to this point. I hope more people feel the same joy I do discovering the kinds of things they can make with the language and frameworks like Rails. With the amazing advancements with the AI tools we have now the only real limits are with how big our imaginations and ambitions can get.
- OpenClawguru 7mo ago
  [dead]
elophanto_agent 7mo ago
[dead]

373 points by stanislavb 7mo ago

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 the focus on writing beautiful and simple code. On making it easy to reason about with colleagues. Now it seems like DHH is throwing all what made Rails special overboard. If we are all supposed to be talking to agents now, what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?

hamandcheese 7mo ago
> 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.
- gfody 7mo ago
  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?
  - vidarh 7mo ago
    The frontier models all handle Ruby just fine. So does th cheap Chinese models like Mini, Qwen, Deepseek.
  - barrkel 7mo ago
    Claude munches through Ruby just fine, all day long.
  - hrmtst93837 7mo ago
    [flagged]
- fy20 7mo ago
  There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well. However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
  - gommm 7mo ago
    Personally I love rust for agents because of types. In the ruby world there's sorbet and rbs so would be interesting to try that.
  - Kerrick 7mo ago
    Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
  - apsurd 7mo ago
    TS is very AI native to the point i'd agree it's near magical in terms of contract. However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy. For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything. you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
    - sodic 7mo ago
      > TS is very AI-native, to the point I'd agree it's near magical in terms of contracts. I agree. Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot. Looking at other candidates: - Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability. - Go is much more usable and very popular, but its type system can't communicate much. - Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity). - etc. I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out. And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
- operatingthetan 7mo ago
  >The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective". The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
quinnjh 7mo ago
>If we are all supposed to be talking to agents now, what's the difference[...]? it's a little cringe, but arguably the benefit of having agents use rails would be tht when you review and audit the agent produced code, you review something that is, as you put it: "beautiful and simple code" and "making it easy to reason about..." I loved rails back in 2017. I may be an outlier but the line tempts me to try it again despite having adopted the who cares attitude to langs. Would be nice to hear from someone first hand if they felt it helped.
Zanfa 7mo ago
> 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 This is so painful... I can't help but wonder who they're trying to target with such inane slogans. Rails is amazing, but "token-efficiency" is not on the list of reasons why.
- stephenr 7mo ago
  > This is so painful... I can't help but wonder who they're trying to target with such inane slogans. The people who think that spicy autocomplete actually has an understanding of the slop it's churning out for them.
  - Zanfa 7mo ago
    Those people don't choose frameworks. It'll be chosen for them by some LLM and given the prevalence of JS, it'll likely be some flavor of React.
- wiseowise 7mo ago
  > This is so painful... I can't help but wonder who they're trying to target with such inane slogans. Typical DHH insanity.
kubafu 7mo ago
I thought you were joking so I went to check it myself and... unfortunately you were not. That is insane.
slopinthebag 7mo ago
Oh boy. I can't even imagine what sort of hell an AI could unleash on a language as dynamic and magical as Ruby...
raincole 7mo ago
Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
mark_round 7mo ago
Author of the article here (hi! Anxiously watching my Grafana stack right now...) I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM. [1]=Well, I had a stronger response initially but I toned it down a bit for here...
apsurd 7mo ago
both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge. fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
imafish 7mo ago
That is just DHH (/37signals) being expert(s) at positioning. Trying to answer the question of, why is language and framework still relevant in a world where almost everyone uses an agent for coding?
graypegg 7mo ago
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 https://news.ycombinator.com/item?id=47272953

ramon156 7mo ago

I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what. I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom. Just to note, its a really boring app thats been done before (odeva.app)

kugelblitz 7mo ago
I usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend. I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around. I think the challenge is to keep working on your old legacy projects. Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
- ramon156 7mo ago
  I totally agree. At my first job, they instantly jumped towards Symfony and AngularJS. Sounds good, but they could've totally gone for something more lightweight. They DID NOT NEED the complexity AngularJS (and Angular2) brought them. When I left I tried my best to update to at least an LTS version, but I did not succeed and they did not care. I believe they're now migrated to Angular2 but are already stuck in hell

bronlund 7mo ago

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.

mark_round 7mo ago
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 ?
- licorices 7mo ago
  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 you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got. Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir. Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
  - marceldegraaf 7mo ago
    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.

paozac 7mo ago

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 actually strongly dislike it

XYen0n 7mo ago
I now also believe that at least Active Record is much easier to use than Django's ORM
- rdevilla 7mo ago
  Doesn't matter when devs just slop out 400 lines of SQL and bypass the ORM. Frameworks and structure will save you from neither stupidity nor ignorance.
  - dewey 7mo ago
    That has always been the case, why would it be different now? Easy to flag and spot in code review.
    - rdevilla 7mo ago
      Boy, I sure wish I had the opportunity to review codebases before inheriting them for maintenance...
      - dewey 7mo ago
        I get your point but this is neither a Rails, nor an AI problem and as old as time.
  - _kblcuk_ 7mo ago
    I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.

neya 7mo ago

One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework. However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them. Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.

slopinthebag 7mo ago
Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
- apsurd 7mo ago
  it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine. that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages. edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever. i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
  - slopinthebag 7mo ago
    I don't get your point, I'm not saying sanitising user input isn't important, I'm saying these JS frameworks are only concerned with server rendering and routing. They don't provide any tooling for databases like Rails or Laravel do.

ssaunier_ 7mo ago

Article nicely written, great overview of Rails current state. Kudos to the author.

dewey 7mo ago

Great post, this has also been my experience in the past 2 years. Rails is just a lot of fun, and that’s especially important for side projects. I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.

pjmlp 7mo ago

Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore". As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive. Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.

wiseowise 7mo ago
> As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive. Not until they get their gradual typing story straight.
- pjmlp 7mo ago
  Depends on how much one likes the Smalltalk, SELF or Lisp development experience, regarding types.

louiskottmann 7mo ago

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.

axelthegerman 7mo ago
And most folks getting stuff done with Rails ain't be filling out surveys to boost their stack - or maybe that's just me. So everyone just stop worrying what everyone else thinks or seems to think and just use the right tools for you and get on with it
- wiseowise 7mo ago
  There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
  - psychoslave 7mo ago
    There are two types of dichotomy: those which are autoreferring and sound, those which are absurd, and those which are really going too far.
fpauser 7mo ago
rails = ruby = oo/mutable && slow && resource hungry
- techpression 7mo ago
  And for a lot of folks that just doesn’t matter. Paying 50 or 100 USD for a server per month won’t be the thing that breaks you. Before you get to a scale where Rails become a problem you need to have a product that drives a pretty significant engagement, that’s where most fail.

misiek08 7mo ago

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. Sit down, write minimal (in case of PHP not so cool looking) code and proceed to next task.

bartread 7mo ago
I've just started using RoR for a live greenfield project since New Year. Honestly, breath of fresh air. It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso than the ones I've listed, which are the ones I used), only it's web development. For me web development has always felt like a frustrating ordeal of keeping track of 10,000 moving parts that add noise and cognitive load and distract you from fixing the actual problems you're interested in solving. This means the baseline ancillary workload is always frustratingly high. I.e., there's too much yak-shaving. Whereas Rails seems to drag that all the way down to a level where it feels more similar to the minimal yak-shaving needed to (at least superficially) build, run, and distribute desktop software. Not that this is without its challenges, because every deployment environment is a little different in the desktop world, but the day to day developer experience is much lower friction that modern web development in general. Also, no sodding TypeScript to deal with. I hate TypeScript: an ugly, verbose, boilerplatey abomination that takes one of the nicest and most fun features of JavaScript (duck typing) and simply bins it off. Awful.
- oorza 7mo ago
  TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.

f311a 7mo ago

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 would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.

vintagedave 7mo ago
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?
- ch4s3 7mo ago
  Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.
- jmusall 7mo ago
  I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
- comboy 7mo ago
  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?
  - vintagedave 7mo ago
    Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.

dalemhurley 7mo ago

Ruby on Rails and Laravel all the way. Solid, proven, stable and scalable.

zhisme 7mo ago

it is also very token efficient in nowadays modern AI driven development[^1]. I wish more people would renown ruby/rails [^1]: https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-file#total-time-and-cost-v1--v2 https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-f...

mergeshield 7mo ago

[flagged]

chrisweekly 7mo ago
Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
matheus-rr 7mo ago
This is the thing people who haven't run a Rails app for years don't appreciate. I went through the Next.js pages router to app router migration on a production app. That wasn't a version bump, it was a rewrite across a different mental model. Rails upgrades are painful but the path is documented, the deprecation cycle gives you a full minor version to fix warnings before they become errors, and the team usually knows where the sharp edges are. The Ruby version management story is actually solid too. rbenv/asdf pin files make it hard to accidentally run the wrong Ruby version, which removes a whole class of environment drift issues you don't even realize you have until you've fixed them.

shanjai_raj7 7mo ago

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.

chrisweekly 7mo ago
nextjs pages -> app router is a massive change: new paradigm, practically replatforming.
- shanjai_raj7 7mo ago
  yes exactly. we had to rewrite most of our data fetching logic. there was no real way to do it gradually, one day we just had to commit and do the whole thing. took way longer than expected.

midnight_eclair 7mo ago

i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs

nick_lt 7mo ago

[dead]

dzonga 7mo ago

Rails for straight up CRUD is top, autogenerated things etc however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django

peepee1982 7mo ago
Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD? I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth. But now, I use AI for scaffolding, and for my side-projects often never have to touch code. So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI? I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
rco8786 7mo ago
FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries. I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
dmix 7mo ago
If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node. Go and Rust fill in lots of gaps for more serious performance stuff.

andrewstuart 7mo ago

Remember only one programming language delivers developer joy - Ruby. No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.

livando 7mo ago

I used to think ruby/rails was the best way to solve most problems, I still do, but I used to too.

neomindryan 7mo ago

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 at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making. Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?

pqdbr 7mo ago
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 how powerful this stack is and how little you have to change in the backend.
- sodapopcan 7mo ago
  I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)
  - shevy-java 7mo ago
    > Maybe not? Because there are fewer and fewer ruby/rails people available. It is the simplest explanation - and the one that makes the most sense, too.

sensanaty 7mo ago

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 these days, though, especially the RoR experience

mattsears 7mo ago
What is it about large untyped codebases that make it a nightmare?
- fourseventy 7mo ago
  If you make a change to the return types of a function for example you have to manually find all of the different references to that function and fix the code to handle the change. Since there are no compile time errors it's hard to know that you got everything and haven't just caused a bug.
  - stouset 7mo ago
    Especially with duck-typing, you might also assume that a function that previously returned true-false will work if it now returns a String or nil. Semantically they’re similar, but String conveys more information (did something, here’s details vs did(n’t) do something). But if someone is actually relying on literal true/false instead of truthiness, you now have a bug. I say this as a Ruby evangelist and apologist, who deeply loves the language and who’s used it professionally and still uses it for virtually all of my personal projects.
  - Salgat 7mo ago
    The best perspective I've seen is that statically typed enforcement is basically a unit test done at compile time.
    - 7mo ago

ClaudeAgent_WK 7mo ago

[flagged]

fnoef 7mo ago

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.

bovermyer 7mo ago
If you like Ruby but don't like Rails, take a look at Crystal, possibly with the Amber framework.

devnotes77 7mo ago

[flagged]

sriramgonella 7mo ago

[flagged]

catlover76 7mo ago
[dead]
gf263 7mo ago
LLM comment Edit: don’t agree? Look at the page!
- deleted 7mo ago
  [deleted]
coreyburnsdev 7mo ago
is this really relevant anymore now that AI has gotten to the level it has? what used to take weeks to setup now take days (react, multiple backend services and infra)
- CodingJeebus 7mo ago
  Very relevant, because it typically takes a lot less code to express a feature in Rails/Hotwire than it does in a SPA with a dedicated back end. No need to maintain API contracts or ensure your UI code is properly async/awaited, etc., etc. Whether its a human or AI writing the code, SPA's add considerable complexity that just isn't necessary for most web apps. Lower LOC to express a feature means better context management which pays dividends for things like code review.
morpheuskafka 7mo ago
This "feels like" first sentence / "curious if" ending question patterns seems to be coming from some LLM? I have seen the same across several online communities suddenly and frequently as of a few weeks ago. Notably the use of "I've seen" and "feels like" suggest the model is either prompted to act as a person or is one of the older models not strongly trained not to.

itsthecourier 7mo ago

try ActiveAdmin, it reduces work a lot. also, ruby is so succinct and rails is so opinionated, Opus is super effective building code and keeping the codebase well structured by default

shevy-java 7mo ago

> Rails seems to have pretty much fallen out of favour, coming in at #20 underneath the bulk of top-10 JavaScript and ASP.NET frameworks It's not just Rails. Ruby is dying. And has been for quite some years now. The strangest things are people writing blog entries claiming the opposite. Like "ruby ages like fine wine". No, that is incorrect - it is dying. I have been using Ruby since about 2004 or 2005. I still use it just about daily. I started before Rails and couldn't care any less about Rails; sadly the ecosystem is infiltrated by corporations such as shopify and others. You can see how they took over RubyCentral effectively (and if they insinuate otherwise - nope, I am not an idiot. I see the pattern. I notice what is happening. You call a black cat a green frog and I call bullshit. It's a black cat. See RubyCentral running amok already before they mass-purged developers, but that's another story - let's go back to ruby, and rails.) > And Ruby itself is nowhere near the top 10 languages, sitting just underneath Lua and freaking Assembly language in terms of popularity! Yup. Ruby is dying. It is following perl. Now, defining "dying" is hard because you still have an active community, even outside of the train wrek that is rails (anyone still caring what random crap DHH writes on his blog? I've noticed fewer people care about the garbage he publishes, other than making fun when shopify damages the ecosystem - oh wait, he sits on the board of shopify. Did I already point out how much damage shopify causes here?). > But I’m a stubborn bastard, and if I find a technology I like, I’ll stick with it particularly for projects where I don’t have to care about what anyone else is using or what the latest trend is. On this part I agree. Ruby as a language is very well designed. It is a great language. I don't think anyone really objects to this, so the criticism has to be split - some criticism is valid, some is not. As a language ruby is well designed. Nonetheless it is dying too. That is also a factual statement. Anyone claiming the opposite is wrong. At the least this is the case right now, and has been in the last some years, to varying extent. > realised Ruby was “a better Perl than Perl”. Also true. Ruby is the better perl. But I actually call Ruby syntactic sugar over C, because this is actually what Ruby is, if you think it through. My use cases are mostly helper-scripts, tons of that, over whatever I do in general. Literally everything computer-related. That includes use cases for the world wide web. All my needs here are covered by Ruby - but not by rails. I don't need rails. Sadly, ruby also has a second problem: documentation. The documentation is crap in general. Look at rack. Opal. WebAssembly for Ruby. That documentation is a joke. An insult. Even sinatra, though better documented than these, has a bad documentation for the most part. There are some exceptions; for instance, hexapdf is well documented, and Jeremy's projects are also well-documented. So I am not saying everything is poorly documented. But for a language that once claimed it wants to compete against python ... sorry, documentation-wise this is still an epic failure point. In some ways ruby actually deserves to follow the path to extinction like perl did, merely because it failed to adjust, adapt and really improve. Yes, there is some internal improvement, but in many ways ruby failed to solve the problems people critisized it for, for many years. And now catching up is SUPER hard. I don't think it can happen anymore. I thought it was possible 10 years ago, but the last 5 years made it clear that ruby is towards extinction. It still does not change me using it, since ruby covers my use cases, but anyone thinking there will be an influx of new young folk driving ruby forward, is just worshipping an illusion here. > There’s just this minimal translation required between what I’m thinking and what I type. That's true. Ruby is kind of transitioning your thoughts into code. > Sure, I can knock things together in Python, Go, or whatever the flavour of the month is, but I always feel on some level like I’m fighting the language rather than working with it. Kind of, though python works fairly well too. > And of course there was the welcoming, quirky “outsider” community feel with characters like Why the Lucky Stiff and their legendary Poignant Guide To Ruby. Well - _why ragequit when someone doxxed him. But even aside from this, I found the poignant guide super-confusing. It was art, but I prefer less confusion myself. Still, _why is gone from the ruby ecosystem. Supposedly he is still doing computer-related stuff in reallife but he is no longer really affiliated with ruby as such. Did I already point out that ruby is dying? > it’s just so nice being able to write things like unless date <= 3.days.from_now I don't doubt that rails is useful, but code like that sucks. Rails also came up with HashWithIndifferentAccess. This simply shows a lack of UNDERSTANDING. They pushed the DSL madness way too far. Yes, I get it, "I don't want to care if we have a string or a symbol" - easier access. But it is the wrong THOUGHT process here. And just the name itself ... HashWithIndifferentAccess versus Hash. Sorry rails guys - you were not good designers in a general sense of the word. The DSL may work; the DSL may be useful, but language or API designers? Nope, sorry. It's awful. if upload_size > 2.megabytes I don't like this either, but I have less reservation here than compared to using numbers for time/date. It's cool that ruby is flexible to allow this, but I still think it is the wrong THOUGHT process.

leke 7mo ago

Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.

gls2ro 7mo ago
Is is the need for static types or the need for better testing that is not focused on coverage of line of code? Because if the domain logic is getting more complex then more types will not catch the bugs unless you are willing for codify business rules within types so then you have to test the types.

itsthecourier 7mo ago

and security. ideally a JS frontend app won't show logic not intended for the user type in question. in practice, really often I see a huge app covering all roles and cases, a trove of info for the red team. and even worse, the reality of software development with LLMs in 2026 is plenty of code is being shipped without security audit. I know it's not an inherent fault of the JS frameworks. bit I share what I see on the streets, most of custom JS apps I see are way more vulnerable to hacking than a old-style MVC app. yes it is possible to make mistakes in both styles, but in JS apps I probably see 400% more easily discovered vulnerabilities than in a common MVC (even with stimulus) app

lowenbjer 7mo ago

I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time. I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty. What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem. Also: God i miss writing Ruby, its a fantastically and beautiful language. Also: Blast from the past: Ruby is a great DSL for Rails.

blandflakes 7mo ago
> I pick tools by the problem, not loyalty. Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though). What did you move onto for those next things you started building?
- lowenbjer 7mo ago
  I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's mostly TypeScript, Go, and Lua.
  - blandflakes 7mo ago
    Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.

systems_glitch 7mo ago

Nothing wrong with Rails in 2026. We still use it for both internal and customer projects. I haven't yet encountered anything that made me feel like switching. I'm also not interested in changing frameworks just to have the New Hotness die in 2-5 years (our oldest currently maintained Rails project is over 10 years old, and some stuff I started working on when Rails 2 was new is still being maintained, just not by us)

butterlesstoast 7mo ago

> sometimes it’s worth doing things just for the sheer hell of it.

desireco42 7mo ago

I always enjoyed Rails, it isn't perfect but is way better then others. I have node and nextjs projects :) when they blow it, it is a major mystery what is blowing up. Have so many good memories working with Ruby. If anyone has old codebase need to be updated and upgraded, refreshed. I am happy to do that.

pier25 7mo ago

I spent 2024 and 2025 trying all the big fullstack monolithic frameworks (Laravel, Rails, .NET, Django). There are differences of course but they all suck so much for doing frontend. In part because for a modern frontend dx you will need hot reload, bundling, etc. But even if you make an SPA and only use eg .NET for an API, using something like OpenAPI to share the schema is a subpar solution. There's really nothing as good as sharing TS types across your whole app(s).

ricardorivaldo 7mo ago

just don't

fixxation92 7mo ago

"I have a tendency to go down rabbit holes when faced with problems - give me a minor inconvenience and I’ll happily spend weeks building something far more elaborate than the situation warrants." You don't know how happy I was to read this... I thought I had a serious problem with getting distracted with my "projects" but it seems this is much more normal than I thought ;-)

deleted 7mo ago

[deleted]

ergocoder 7mo ago

I unfortunately don't want to work on an untyped codebase anymore. It's been 20 years, and Ruby/Rails still can't get their typing working.

tianrking 7mo ago

[flagged]

yazantapuz 7mo ago

Ohmygod. Reading all that blog posts about RoR in Google Reader and is the old fashioned way now?

liamgriffiths 7mo ago

To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/ https://sorbet.org/ Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type system for writing and understanding conventional software. I'm rooting for further developments in this space because I love language and systems that can leverage it's strengths and layering on a type system makes it a very formidable technology for building real world products. I have not used Rails in a few years, but I can also say that the Sorbet typing support for the framework is definitely there too -- to great credit to the folks at Shopify allowing users of the framework to benefit from this tooling. I would happily work on a Rails system today too. It's an amazing testament to the community how the design has been able to continue to develop to meet the needs of the many developers building with it up to this point. I hope more people feel the same joy I do discovering the kinds of things they can make with the language and frameworks like Rails. With the amazing advancements with the AI tools we have now the only real limits are with how big our imaginations and ambitions can get.

OpenClawguru 7mo ago
[dead]

elophanto_agent 7mo ago

[dead]