[HN Gopher] Returning to Rails in 2026
___________________________________________________________________
Returning to Rails in 2026
Author : stanislavb
Score : 326 points
Date : 2026-03-12 06:06 UTC (16 hours ago)
(HTM) web link (www.markround.com)
(TXT) w3m dump (www.markround.com)
| shafyy wrote:
| 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 wrote:
| > 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.
| fy20 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| sodic wrote:
| > However having worked with Typescript for 8 years now...
| I'm not sure I could go back to Ruby without types.
|
| Very true for me as well. I've never worked with Ruby but
| feel the same way about Django.
|
| Btw, if you're looking for a "Rails but with TypeScript,"
| my colleagues and I are working on almost just that:
| https://wasp.sh/.
|
| The main difference, besides the ecosystem, is that we're
| more in the "configuration over convention" camp. Wasp has
| a simple DSL for specifying said configuration, but it's
| about to be replaced with a TypeScript file.
|
| Wasp is still in beta and nowhere near Rails-level polish.
| But, depending on your early adopter tendencies, you might
| find it interesting regardless. If you do try it out,
| please reach out and share your thoughts.
| gfody wrote:
| 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 wrote:
| The frontier models all handle Ruby just fine. So does th
| cheap Chinese models like Mini, Qwen, Deepseek.
| barrkel wrote:
| Claude munches through Ruby just fine, all day long.
| hrmtst93837 wrote:
| Python does have a bigger pool of examples, but agents
| usually get tripped up by missing context about specific
| frameworks more than by language syntax. The real obstacle
| for LLMs is understanding Rails' implicit conventions and
| magic, not the Ruby language itself.
| operatingthetan wrote:
| >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 wrote:
| >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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| > This is so painful... I can't help but wonder who they're
| trying to target with such inane slogans.
|
| Typical DHH insanity.
| kubafu wrote:
| I thought you were joking so I went to check it myself and...
| unfortunately you were not. That is insane.
| slopinthebag wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| ramon156 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gedy wrote:
| I think the OP's point was the job market. I.e. you
| probably aren't hiring for that role.
| marceldegraaf wrote:
| Not OP, but I made the move from Ruby/Rails to Elixir years
| ago, so I'll try to answer from my perspective.
|
| Elixir is a functional programming language based on the
| "BEAM", the Erlang VM. We'll get back to the BEAM in a
| moment, but first: the functional programming aspect. That
| definitely took getting used to. I remember being _very_
| confused in the first few weeks. Not because of the syntax
| (Elixir is quite Ruby-esque) but because of the "flow" of
| code.
|
| However, when it clicked, it was immediately clear how easy
| it becomes to write elegant and maintainable code. There is
| no global state in Elixir, and using macros for meta-
| programming are generally not encouraged. That means it
| becomes very easy to reason about a module/function: some
| data comes in, a function does something with that data, and
| some data comes out. If you need to do more things to the
| data, then you chain multiple functions in a "pipe", just
| like how you chain multiple bash tools on the command line.
|
| The Phoenix framework applies this concept to the web, and it
| works very well, because if you think about it: a browser
| opening a web page is just some data coming in (an HTTP GET
| request), you do something with that data (render a HTML
| page, fetch something from your database, ...) and you return
| the result (in this case as an HTTP response). So the flow of
| a web request, and your controllers in general, becomes very
| easy to reason about and understand.
|
| Coming back to the BEAM, the Erlang VM was originally written
| for large scale (as in, country size) telephony systems by
| Ericsson. The general idea is that everything in the BEAM is
| a "process", and the BEAM manages processes and their
| dependencies/relationships for you. So your database
| connection pool is actually a bunch of BEAM processes. Multi-
| threading is built-in and doesn't need any setup or
| configuration. You don't need Redis for caching, you just
| have a BEAM process that holds some cache in-memory. A
| websocket connection between a user and your application gets
| a separate process. Clustering multiple web servers together
| is built into the BEAM, so you don't need a complex
| clustering layer.
|
| The nice thing is that Elixir and Phoenix abstract most of
| this away from you (although it's very easy to work with that
| lower layer if you want to), but you still get all the
| benefits of the BEAM.
| MrWiffles wrote:
| Something I never quite understood: differentiate between
| BEAM process and operating system process. The OS has
| launched one (in theory) BEAM Erlang VM runtime process
| with N threads; are we saying "process" here to try to
| emulate the OS process model internally within the BEAM OS
| process, when really we're talking about threads? Or a mix
| of threads and other processes? I'm imagining the latter
| even cross network, but am I at least on the right track
| here?
| marceldegraaf wrote:
| A BEAM process is not an OS thread. The way I understand
| it, a BEAM process is just a very small memory space with
| its own heap/stack, and a message system for
| communication between BEAM processes.
|
| The BEAM itself runs multiple OS threads (it can use all
| cores of the CPU if so desired), and the BEAM scheduler
| gives chunks of processing time to each BEAM process.
|
| This gives you parallel processing out of the box, and
| because of the networking capabilities of the BEAM, also
| allows you to scale out over multiple machines in a way
| that's transparent to BEAM processes.
| bronlund wrote:
| When I first started out with Elixir, it was more the overall
| architecture that first sold it to me. It is remarkably
| robust, my impression is that you can more or less yank RAM
| modules out of the server while it is running, and the last
| thing which will crash is Elixir. And it is absolutely top in
| class when it comes to parallel processing and scaleability.
| Not only how it does it internally, but also how it abstracts
| this in a way that just makes sense when you are working with
| it.
|
| When it comes to web development specifically, what really
| got me hooked, was LiveView from the Phoenix framework. It
| keeps a persistant WebSocket connection to the client which
| it uses to push DOM updates directly. Instead of the usual
| request/response cycle on the client side, the server holds
| the state and just pushes the diff to the browser. It just
| made so much sense.
| cpursley wrote:
| I've put together a number of resources here:
| https://elixirisallyouneed.dev
| bronlund wrote:
| Great site. Thanks.
| freedomben wrote:
| I am/was a huge Ruby fanboy, and I used Rails a lot and loved
| it (though had some criticisms around too much "magic"). I
| made the jump to Elixir/Phoenix around 8 years ago, and have
| loved it. Phoenix to me basically "fixed" all the things I
| didn't like about Rails (basically opacity and hard-to-find-
| where-it's-happening stuff due to someone metaprogramming
| aggressively). I will admit that I've been a functional
| programming fan for a very long time too. I always write my
| ruby code in a functional style unless there's a good reason
| not to (which is increasingly rare).
|
| I still love and use ruby a ton for scripting, and still
| reach for Sinatra for super simple server needs, but Phoenix
| is my go-to stack these days.
|
| I've also found the Elixir community to be amazing in the
| same ways the Ruby community is/was. It's not all roses, for
| example there's not as many libraries out there. Distribution
| is also not awesome so for example I currently use ruby or
| rust when writing CLIs. But for anything distributed
| (especially web) Phoenix is amazing.
|
| This is a self plug, but I did a conference talk introducing
| Ruby veterans to Elixir/Phoenix some years ago. It's probably
| aged a bit, but should still be pretty accurate.
| https://www.youtube.com/watch?v=uPWMBDTPMkQ
|
| The original conference talk is here
| (https://www.youtube.com/watch?v=sSoz7q37KGE), though the
| made-for-youtube version above is better because it's
| slightly updated, and I didn't run out of time :-)
| paozac wrote:
| 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 wrote:
| I now also believe that at least Active Record is much easier
| to use than Django's ORM
| rdevilla wrote:
| 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 wrote:
| That has always been the case, why would it be different
| now? Easy to flag and spot in code review.
| rdevilla wrote:
| Boy, I sure wish I had the opportunity to review
| codebases before inheriting them for maintenance...
| dewey wrote:
| I get your point but this is neither a Rails, nor an AI
| problem and as old as time.
| _kblcuk_ wrote:
| 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.
| neocron wrote:
| If have a different opinion on this, as I think it's 100x
| better to learn sql and just write it directly instead of
| using the dozens of leaky abstraction of some framework.
| Zanfa wrote:
| > 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
|
| This is the primary issue with Rails in my experience. It takes
| intentional effort to internalize the idioms before it clicks
| and you unlock the magic that makes it so insanely productive.
| JS devs will keep trying to force backend business logic into
| Franken-React Stimulus components and complaining it's not very
| good.
| paozac wrote:
| Yes, I've seen that, too. The rails way of doing things can
| feel like a terrible limitation to some developers, while
| others enthusiastically embrace it
| e12e wrote:
| I'd say that if you're first encounter with rails is version 8+
| -- it's a lot easier to use than previous versions.
|
| Partly because the handling of JavaScript is much less bespoke
| and complex.
| paozac wrote:
| Javascript handling in Rails was easy in the early versions,
| then became messy with the asset pipeline and webpacker, and
| is becoming simple again with the latest versions
| neya wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| apsurd wrote:
| JS frameworks are very much in the "full-blown app"
| category.
|
| As an example, the "react" is just a view layer is a
| purest pov, to me (or whatever the given framework in
| question is). Nextjs, Vercel, supabase, lovable, and so
| on down the line all empower millions of people to ship
| full-blown apps. We might get carried away with which
| specific layer is in question, but it doesn't matter if
| they're always used together to ship millions of
| (in)secure apps.
| chuckadams wrote:
| SQL injection is prevented by using database APIs properly,
| not sanitizing. Put all the malicious SQL you want in a
| query string, if it's passed as a bound parameter to a
| prepared query, it's only ever going to be a plain string.
|
| You might sanitize for different reasons like business
| logic, but if it's your first line of defense against sql
| injection, you're already on the losing side.
| dalemhurley wrote:
| The difference between JS frameworks and RoR/Laravel is the
| ecosystem cohesion. RoR and Laravel ecosystems employ the RoR
| or Laravel way of doing things and everything works together
| very smoothly.
|
| JS solutions are loosely coupled, lots of good reasons to do
| so, but comes at a major complexity cost.
| neya wrote:
| I agree. Opinionated frameworks are better in this regard.
| BoorishBears wrote:
| Eh, there's NestJs and AdonisJs if you want opinionated MVC
| with lots of built-ins like CSRF and ORMs.
|
| But you can also pick tight packages that do one thing well.
| Something like oRPC + Drizzle that lets you pipe data from your
| database to frontend with full typing and cross-boundary go-to-
| definition while covering most of what Nest and Adonis do with
| better focused APIs.
|
| And in terms of security, I'll take Typescript with a strong
| compiler config anyday. For example, I disable: `any`, non-null
| asserts (no `!`), floating promises without `void` for
| explicitness, no unnecessary conditions, and a bunch of other
| strict rules. I also use Branded Types liberally. All of that
| makes logical errors that can become app-specific security
| issues (and are thus less readily detected) much less likely to
| happen. And as a bonus you get really reliable code too.
| jeppester wrote:
| Give AdonisJS a try, it's pretty much the JS sibling of Laravel
| and RoR.
| neya wrote:
| Thanks! Never heard of it, definitely will check it out.
| e12e wrote:
| Adonis is nice, but still young and lacking features. And in
| my experience very verbose compared to rails.
|
| That said, absolutely worth a look.
| ssaunier_ wrote:
| Article nicely written, great overview of Rails current state.
| Kudos to the author.
| dewey wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Depends on how much one likes the Smalltalk, SELF or Lisp
| development experience, regarding types.
| louiskottmann wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| rails = ruby = oo/mutable && slow && resource hungry
| techpression wrote:
| 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.
| mark_round wrote:
| The "one-person framework" thing is a big draw. I'm amazed at
| how productive I was in it, and it's not just at the code
| level. Even though I've been doing sysadmin/devops/architect
| work for over 25 years now, it's just so damn nice now not to
| have to think about e.g. standing up a HA PostgreSQL cluster or
| Redis and deployment is largely a solved problem.
| etothet wrote:
| Over TWO decades! Rails has been around since 2004, making it
| just slightly younger than Django.
|
| edit: Django was release in 2005
| sarchertech wrote:
| Rails is definitely older than Django. Django wasn't released
| publicly until 2005.
|
| Django had private use before then, but rails was also in
| private use before it was released.
| pushcx wrote:
| Rails's public release was July 2004:
| https://rubytalk.org/t/ann-rails-0-5-0-the-end-of-
| vaporware/...
|
| Django's was July 2005:
| https://www.djangoproject.com/weblog/2005/jul/15/chipy/
| etothet wrote:
| Adding Simon Willison's announcement:
| https://simonwillison.net/2005/Jul/17/django/
| etothet wrote:
| Thanks for the correction!
| monooso wrote:
| Two decades. Rails was released in 2004, IIRC.
| miguno wrote:
| > In the latest Stackoverflow survey, it's back at the "top 5
| of desired stacks to use for next project" over a decade after
| its inception !
|
| Oh, where did you find that?
|
| Only info I could find was that Rails is at rank 10 in the Web
| Frameworks category for Admired vs. Desired in the 2025 survey:
| https://survey.stackoverflow.co/2025/technology/#2-web-
| frame....
| misiek08 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nathanappere wrote:
| But we need contracts that go way further what static
| typing provides. If they add dependant types + ability to
| enforce the types at runtime so that you can use it on
| various inputs, then maybe it will be truly useful.
| bartread wrote:
| > Either you are using the wrong vocabulary or I don't
| think you've bothered to actually learn Typescript.
|
| All right, fine: TypeScript uses structural typing which is
| if you like a specialisation of duck typing but, whatever,
| compared with JS's unadorned duck typing it still leads to
| embellishment of the resulting code in ways that I don't
| enjoy.
|
| I've been using TypeScript across different projects at
| different companies since 2013 and I've absolutely given it
| an honest go... but I just don't like it. I even allowed
| its use at a mid-size company where I was CTO because it
| fit well with React and a sensible person picks their
| battles, but I still didn't like it.
|
| I'm now in the very privileged position where I don't have
| to use it, and I don't even have to allow it a foot in the
| door.
|
| Now I'm sure that won't last forever, and I'll have to work
| with TypeScript again. I'll do it - because I'm a
| professional - but I'm still entitled to an opinion, and
| that opinion remains that I don't like the language. After
| 13 years of use I feel pretty confident my opinion has
| settled and is unlikely to change. I find it deeply
| unenjoyable to work with. BUT the plus side is that in the
| era of LLMs perhaps I no longer need to worry so much about
| have to deal with it directly when it eventually does
| impinge upon my professional life again.
| x0x0 wrote:
| I found it not just to lead to embellishment, but (1) the
| problems it did flag mostly would be caught by minimal
| testing; whereas (2) it regularly missed deeper problems.
| For an example of the latter: using TanStack (React
| Query) api caching, you have different data shapes for
| infinite scroll vs non infinite scroll. There were
| circumstances were an app confused them. Typescript had
| nothing to say. Nominal typing easily handles these cases
| and, ime, caught more actual problems.
| bovermyer wrote:
| I have my complaints about the JS/TS ecosystem, but I'm
| surprised to see a comment that it's verbose and
| "boilerplatey."
|
| Could you elaborate on that?
| JeremyNT wrote:
| If you're solving problems rails is best at, it's borderline
| magical.
|
| The troubles arise when you get to huge codebases or
| complicated frontend patterns that aren't ideal for SSR /
| hotwire.
|
| Also, it's impossible to separate Rails from DHH, whose
| xenophobic politics are unfortunately front and center.
| psychoslave wrote:
| What is STOA standing for here, please?
| wasting_time wrote:
| Likely a typo of State Of The Art.
| trusche wrote:
| FTA:
|
| > There's just this minimal translation required between what
| I'm thinking and what I type
|
| That's really the essence of Ruby for me.
| f311a wrote:
| 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 wrote:
| 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 wrote:
| Indeed that's what a lot of Elixir and Erlang packages do, if
| it's done then it's done.
| jmusall wrote:
| 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 wrote:
| 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 wrote:
| Perhaps some kind of 'this code is still alive' flag is
| key. Even just updating the project. Watching issues.
| Anything showing 'active but done'.
| 9rx wrote:
| That depends. What problem do I have, exactly?
|
| Do I need a library to sort an array? The 5 years ago
| option is going to be the more likely choice. A library
| updated 2 weeks ago is highly suspicious.
|
| Do I need a library to provide timezone information? The 2
| weeks ago option, unquestionably. The 5 years ago option
| will now be woefully out of date.
| zelphirkalt wrote:
| The issue with that is, that the longer you wait to upgrade
| dependencies, the more pronounced the problems upgrading it
| will become generally speaking, because more
| incompatibilities accumulate. If those 5-6 year old projects
| were updated every now and then, then the pain to get them
| updated would be far less. As you point out, security is an
| aspect too, so you can leave the project inactive, but then
| you might hit that problem.
| igsomething wrote:
| Dependency hell. Usually how it goes is you have to develop a
| new feature, you find a library or a newer version of the
| framework that solves the problem but it depends on a version
| of another library that is incompatible with the one in your
| project. You update the conflicting dependency and get 3 new
| conflicts, and when you fix those conflicts you get 5 new
| conflicts, and repeat.
| vintagedave wrote:
| So churn causes more churn.
|
| Also breaking APIs should be regarded very poorly. It
| isn't. But it should be.
| chrisweekly wrote:
| "Security fixes aside" is too dismissive. Transitive
| dependencies with real CVEs can feel like the tail wagging
| the dog, but ignore them at your peril.
| stevepike wrote:
| The real issue with Rails apps is keeping up with the
| framework and language versions. There are really two
| categories of dependencies.
|
| One-off libraries that don't have a runtime dependency on
| Rails are typically very low-maintenance. You can mostly
| leave them alone (even a security vulnerability is unlikely
| to be exploitable for how you're using one of these, as often
| user input isn't even getting through to them). For instance
| a gem you install to communicate with the stripe API is not
| typically going to break when you upgrade Rails. Or adding
| httparty to make some API requests to other services.
|
| Then there are libraries that are really framework
| extensions, like devise for authentication or rspec for
| testing. These are tightly coupled to Rails, sometimes to its
| private internals, and you get all sorts of nasty
| compatibility issues when the framework changes. You have to
| upgrade Rails itself because you really do need to care about
| security support at that level, even for a relatively small
| company, so you can end up in a situation where leaving these
| other dependencies to fester makes upgrading Rails very hard.
|
| (I run a startup that's a software-enabled service to upgrade
| old Rails apps).
| BeefySwain wrote:
| Does batteries included somehow result in upgrading years old
| projects being a larger lift? I would think the opposite.
| f311a wrote:
| My medium-sized Django projects had close to 100
| dependencies, and when you want to update to a new Django
| version, the majority of them must be updated too.
|
| Thankfully, updating to a new Django version is usually
| simple. It does not require many code changes.
|
| But finding small bugs after an update is hard, unless you
| have very good test coverage. New versions of
| middleware/Django plugins often behave slightly differently,
| and it's hard to keep track of all the changes when you have
| so many dependencies.
| Lukas_Skywalker wrote:
| I also think it's the opposite, since the dependencies are
| almost guaranteed to be compatible with each other. And I
| think Ruby libraries in particular are usually quite stable
| and maintained for a long time.
| thedanbob wrote:
| My experience has been the opposite, especially since Rails
| has included more batteries over the years. You need fewer
| non-Rails-default dependencies than ever, and the upgrade
| process has gotten easier every major version.
| dmix wrote:
| Rails is way more stable and mature these days. Keeping up
| to date is definitely easier. Probably 10x easier than a
| Node/JS project which will have far more churn.
| sebra wrote:
| I'm working on a large (at least 300k+ loc) Django code base
| right now and we have 32 direct dependencies. Mostly stuff like
| lxml, pillow and pandas. It's very easy to use all the nice
| Django libs out there but you don't have to.
| f311a wrote:
| I was talking about total deps, not direct. By installing
| something like Celery, you get 8-10 extra dependencies that,
| in turn, can also have extra deps. And yeah, extra deps can
| conflict with each other as well.
| louiskottmann wrote:
| I find the thought daunting but the reality surprisingly
| easy.
|
| You just keep up as you go, as long as you keep things
| close to the framework it's fine.
| IshKebab wrote:
| > You just keep up as you go
|
| He said "Updating a project that was started 5-6 years
| ago takes a lot of time."
| WJW wrote:
| Yes but GP said "In reality it's not that much".
| bryanlarsen wrote:
| Not much work every few months turns into a lot over
| years, especially if you skip a few of those "every few
| months" events.
| tomnipotent wrote:
| I'm confused. It's too much work to upgrade dependencies,
| but not too much time to write from scratch and maintain,
| in perpetuity, original code?
| bryanlarsen wrote:
| Yes. I've probably spent more time maintaining a trivial
| Rails app originally written in 2007 than I spent writing
| it in the first place.
| WJW wrote:
| That is obviously true but doesn't mean as much as you
| seem to think. Washing laundry is also not much work but
| it adds up to a lot over the years, especially if you
| skip a few weeks of laundry every once in a while. That
| is not an excuse to not do it.
|
| The answer is the same in both cases: acquire some
| discipline and treat maintenance with the respect it
| deserves.
| graemep wrote:
| It is easy, and people tend to do what is easy. It takes more
| effort to minimise dependencies. Your boss or your client
| will not even notice.
|
| Obviously there are some dependencies that you cannot easily
| avoid (like the things you mention). On the other hand there
| is a lot off stuff used that is not that hard to avoid -
| things like wrappers for REST APIs are often not really
| necessary.
| ncphillips wrote:
| I have not had this experience as badly with Laravel. Their
| libraries seem much more stable to me. We've gone up 5 major
| versions of Laravel over the last year and a half and it was
| pretty simple for each major version.
| dalemhurley wrote:
| Laravel is extremely stable and consistent.
| nikanj wrote:
| In my experience, the magic makes the easy parts easier and the
| hard parts harder
| nurettin wrote:
| It used to take at least a day of work. In a post-2025/11
| world, it is under an hour. Maybe even 15 minutes if you've
| landed on a high quality LLM session.
| kshahkshah wrote:
| Complete opposite of my experience
| __mharrison__ wrote:
| Use UV for dep management. Make sure you have tests.
|
| In the past month I migrated a 20 year old Python project (2.6,
| using the pylons library) to modern Python in 2 days. Runs
| 40-80 times faster too.
| the__alchemist wrote:
| Different experience with Django. I am only using a handful of
| deps. dj-database-url, dj-static, gunicorn, psycopg are the
| only "mandatory" or conserved one IMO as a baseline.
| itsthecourier wrote:
| I have plenty of RoR in production with millions of users,
| yearly we upgrade the projects and it's fine, not as
| catastrophic as it sounds, even easier with Opus now
| coffeefirst wrote:
| It really depends how they were built. I have large Django apps
| running for a very long time that require minimal maintenance,
| but it's because we were very deliberate about dependencies.
|
| But I learned to do that by working on codebases that were the
| opposite.
| dalemhurley wrote:
| Ruby on Rails and Laravel all the way. Solid, proven, stable and
| scalable.
| zhisme wrote:
| 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-f...
| mergeshield wrote:
| The upgrade story is underrated. I've maintained Next.js projects
| where major version upgrades broke fundamental patterns (pages
| router - app router, completely different data fetching). Rails'
| deprecation-then-removal cycle is slower but way less disruptive.
| When you're shipping product, stability of the interface you
| build against matters more than having the latest paradigm.
| chrisweekly wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| nextjs pages -> app router is a massive change: new paradigm,
| practically replatforming.
| midnight_eclair wrote:
| 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
| dzonga wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I used to think ruby/rails was the best way to solve most
| problems, I still do, but I used to too.
| neomindryan wrote:
| 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 resume 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| sodapopcan wrote:
| Well ya, I'm just saying I'm surprised considering the
| current job market. I moved on from Rails about 5 years
| ago now, but have 9 years experience under my belt and
| still keep up a bit with new things and play with them
| once in a while. And yet I've applied for several Rails
| positions in the past few years and always get an
| outright rejection.
| shevy-java wrote:
| > Does anyone think NPM's 3.1 million packages enable more
| functionality than RubyGems' 190,000 packages?
|
| It means that there are many more people using NPM.
|
| That means more users. More users is almost always better, for
| any language.
|
| Also many of those gems on rubygems are dead since decades,
| literally. Probably also for NPM. We can not just compare the
| numbers without analysis.
| sensanaty wrote:
| 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
| kshahkshah wrote:
| Are you hand coding?
| h4ch1 wrote:
| Are we that far gone that "hand coding" is a term now? I hope
| there's an /s missing
| konart wrote:
| I hope "hand coding" is an antonym for "convention coding"
| or something.
| evolve2k wrote:
| I'm guessing hand coding means, not vibe coding.
|
| Did you use AI? .. Nah I hand coded it.
| Cyphase wrote:
| Real programmers use butterflies. https://xkcd.com/378/
| satvikpendem wrote:
| Doesn't matter because LLMs also benefit greatly from typed
| code bases in that they can run the type checker and fix the
| problems themselves on a loop.
| le-mark wrote:
| I haven't seen much discussion about this point other than
| "llm handle languages x y and z because there's a lot of
| training data". Watching Terence Tau using llm for writing
| proofs in Lean was a real eye opener in this regard.
| vidarh wrote:
| Both Claude and Codex handle Ruby just fine.
| draw_down wrote:
| I've worked in two places now with Ruby Sorbet servers. Ruby
| always drives me nuts how things are just in-scope and we don't
| know why or where they came from.
|
| I certainly wouldn't want to go back to working in dynamic
| languages without typing on top. That takes too much brain
| power, I'm too old for that now.
|
| I would say Sorbet seems more "basic" than something like
| Typescript. It handles function calls matching signatures,
| potential nulls, making sure properties actually exist, that
| kind of thing. Whereas TS can get quite abstract, and at times
| you're fighting to convince it that a value actually is the
| type you say it is.
|
| TS is very powerful and expressive, to the point that it's
| possible to do computation within type code. I'm not convinced
| I always need that power, or that it's always more help than
| hindrance.
| wutwutwat wrote:
| > I certainly wouldn't want to go back to working in dynamic
| languages without typing on top. That takes too much brain
| power, I'm too old for that now.
|
| > and at times you're fighting to convince it that a value
| actually is the type you say it is.
|
| Might just be allocating that brain power to the same task
| but calling it a different thing.
| vidarh wrote:
| > Ruby always drives me nuts how things are just in-scope and
| we don't know why or where they came from.
|
| irb(main):005:0> Foo.new.method(:bar).source_location =>
| ["tmp/test.rb", 5]
| vidarh wrote:
| You appear to be shadow banned. Letting you know since I
| didn't see anything egregious on a quick scan. Maybe contact
| HN and plead your case.
|
| I vouched for your reply below, and to answer in the
| meantime:
|
| Yes, it's runtime, but that only matters if your code can't
| be initialized without unacceptable side effects.
|
| In which case you don't have a functioning test suite either,
| and have much larger problems.
|
| Otherwise, just load the code you struggle to figure out into
| irb, or pry, or a simple test script, and print out source-
| location.
|
| If that is impossible (aside from the fact that codebase is
| broken beyond all reason), the marginally harder solution is
| to use ruby-lsp[1] and look up the definitions.
|
| This is only hard if you insist on refusing to use the
| available - and built in, in the case of source_location -
| tooling.
|
| 1: https://shopify.github.io/ruby-lsp/
| paride5745 wrote:
| Rust/Loco is unironically the most interesting framework right
| now.
|
| Loco follows up the Rails formula pretty closely, and makes
| easier to learn Rust by taking care of a load of boilerplate
| code.
| the__alchemist wrote:
| Concur on most interesting! I really hope it works out, but
| am cautious.
|
| It is surprising to me seeing the rust web backend scene;
| many libraries, server frameworks, and users, but they are
| all Flask-analogs, without the benefit of the reasonably-
| robust ecosystem Flask has. My suspicion is that people are
| using them for micro-services and not websites/webapps, but I
| haven't been able to get a straight answer on this about how
| people are using these tools. I.e. even though rust is my
| favorite overall language and see no reason it couldn't be
| used for web work, I still use Django.
|
| Axos, Axum, Rocket, Diesel etc, are all IMO not in the same
| league as Django. My understanding is that addressing this is
| Loco's Raison d'etre.
|
| Another aspect of the Rust web ecosystem: It's almost fully
| gone Async.
| JeremyNT wrote:
| It's quite a gap really.
|
| I'll say this, coding agents make the lack of a "batteries
| included" framework like rails or Django somewhat less
| daunting.
|
| But "convention over code" and having a default structure /
| shape for projects is extremely helpful and you feel it
| when it's missing.
|
| For my last small project I looked at Loco but ended up
| passing on it because I felt like adoption wasn't great
| yet. I really hope it takes off, though.
| thiago_fm wrote:
| Same. Also became a .net developer after almost 20 years of
| Ruby/Rails.
|
| Nowadays C# is anyways much more expressive than before.
| Meanwhile Ruby is still very slow.
|
| Not to mention how poorly maintained are most Rails projects.
| People have been "vibe coding" forever.
|
| A well-organized and maintained Rails app is great though. I'd
| definitely consider working with it again, but it really
| depends on what company it is.
| ptak_dev wrote:
| Twenty years in Rails and then switching to .NET -- that is a
| significant career move. I think a lot of people
| underestimate how much institutional knowledge transfers
| between ecosystems though. MVC patterns, understanding ORMs
| deeply, debugging N+1 queries, structuring background jobs --
| all of that carries over regardless of whether you are
| writing Ruby or C#.
|
| The tricky part is not the technical transition itself, it is
| how you communicate it. Hiring managers and recruiters often
| pattern-match on tech stacks: they see "20 years Ruby" and
| mentally put you in a box. The real skill is reframing that
| experience so the architectural depth comes through, not just
| the language.
|
| I have been thinking about this problem a lot -- how do you
| help developers articulate what actually makes them valuable
| when they switch contexts? I built a tool (https://super.myni
| nja.ai/apps/6de082c7-a05f-4fc5-a7d3-ab56cc...) that uses AI
| to help reframe experience for different roles and tech
| stacks. It has been interesting to see how much better "20
| years building production systems across Ruby and C#" reads
| compared to "Ruby developer now doing .NET".
| mattsears wrote:
| What is it about large untyped codebases that make it a
| nightmare?
| fourseventy wrote:
| 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 wrote:
| 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 wrote:
| The best perspective I've seen is that statically typed
| enforcement is basically a unit test done at compile time.
| goatlover wrote:
| Alan Kay's argument against static typing was it was too
| limited and didn't capture the domain logic of the sort
| of types you actually use at a higher level. So you leave
| it up to the objects to figure out how to handle
| messages. Given Ruby is a kind of spiritual ancestor of
| Smalltalk.
| array_key_first wrote:
| Yes, and the downsides cascade. Because making any change
| is inherently risky you're kind of forced not to make
| changes, and instead pile on. So technical debt just grows,
| and the code becomes harder and harder to reason about. I
| have this same problem in PHP although it's mostly solved
| in PHP 8. But touching legacy code is incredibly involved.
| weavejester wrote:
| Is that a common issue? I guess I'm having a hard time
| imagining a scenario that would (a) come up often and (b)
| be a pain to fix.
| aarestad wrote:
| It makes coming up to speed on an existing codebase a slog
| because you have to trace through everything back to its
| source. Oh, and because there are magic methods and
| properties galore, your normal introspection tools in e.g.
| RubyMine get frequently stymied.
| Larrikin wrote:
| Anything can return anything and you only realize it at
| runtime is a massive headache. When you can't keep the entire
| code base in your head it becomes a liability.
|
| I never used Ruby, but Python code bases love mixing in
| strings that are actually enums and overloading functions
| that accept all kinds of types. You just had to hope that the
| documentation was correct to avoid a crash.
|
| Java 1.7 to Python feels very freeing from all the
| boilerplate. Kotlin, or any other modern language with a well
| designed standard library, to Python just feels like a bunch
| of extra mental work and test to write to just avoid
| brackets.
| eudamoniac wrote:
| I worked with Rails a lot. In my experience, every rails dev
| who is fanatical about how much they love Rails, also has
| little to no experience with strong types. Of the ones who
| later try types, they no longer love Rails. Personally I quit
| Rails entirely because of lack of types. No, RBS and Sorbet are
| not even close to good enough.
|
| Also, every enterprise rails app I've seen (seven, to date) has
| been really poorly written/architected in a way that other
| backends just weren't. Even the fairly new ones felt like
| legacy code already.
| mike_ivanov wrote:
| Ruby is a strongly typed language. I think you are confusing
| strong typing with static typing.
| goatlover wrote:
| And by contrast, C is static but weakly typed.
| schlch wrote:
| I still really like rails. It's really fun until your
| codebase reaches a certain size. At that point you better
| have a large suite of test which becomes a problem of it self
| because the tests will take forever to complete.
|
| I tried sorbet a couple of times and totally get why it's
| useful but imo it's not just lacking (e.g. compared with what
| can be done with TS or even a simple type system like golang)
| but it also removes all the fun parts of ruby / rails.
| rdoherty wrote:
| It's not just the untyped problems, the runtime definitions of
| functions, properties, etc make it nearly impossible to debug
| unless you have the _state_ of your production data locally.
| (Or you ssh into your prod server and open up a REPL, load the
| state and introspect everything there). Good luck debugging
| locally in a nice IDE. It 's a horrific nightmare. I use to
| love Ruby until I had to debug it live.
| fnoef wrote:
| 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 wrote:
| If you like Ruby but don't like Rails, take a look at Crystal,
| possibly with the Amber framework.
| devnotes77 wrote:
| The upgrade path in Rails 8 is smoother than it's ever been,
| especially with the built-in solid adapters removing the
| Redis/Sidekiq dependency for smaller apps.
| itsthecourier wrote:
| 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 wrote:
| > 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.
| shevy-java wrote:
| > got Claude to generate the rest with some mockups of common
| screens and components.
|
| And AI is doing the rest. The path to exctinction.
|
| Does Claude make "scripting" languages obsolete? I mean that
| knowledge becomes less useful if AI autogenerates everything.
|
| > This can be something simple like caching for a specific time
| period: <% cache "time_based", expires_in:
| 5.minutes do %> <!-- content goes here --> <%
| end %>
|
| I absolutely hate ERB. It is strange that it is such an
| integral part of rails.
|
| I abandoned PHP for many reasons but one was the spaghetti
| problem. Rail has the same spaghetti problem, though ruby is
| prettier than PHP. Still, that spaghetti design is just awful.
|
| > This is why services like Heroku and Pivotal Cloud Foundry
| thrived back then
|
| Heroku is also in the process of dying. There were some recent
| discussions about it on reddit as to why.
|
| > While the Stack Overflow survey isn't necessarily an accurate
| barometer of developer opinion, the positions of Ruby and Rails
| do show it's fallen from grace in recent times.
|
| It's not just SO though. TIOBE, despite being crap, also shows
| a similar trend. And if you research things, you notice many
| people moved on from ruby, for many reasons - often work-
| related.
|
| The numbers are all there though. Now people either believe the
| numbers - or they write fake analysis such as this here:
| https://medium.com/railsfactory/ruby-is-not-dying-its-aging-...
|
| > Anecdotally, I find a lot of documentation or guides that
| haven't been updated for several years and the same goes for a
| lot of gems, plugins and other projects.
|
| Yup. A dying ecosystem. I stopped using rubygems.org myself
| after Marty pushed the ecosystem into shopify's corporate pet
| project. 100.000 downloads and then your project is hijacked?
| Or the new shiny corporate rules? Nah. Go to corporate land and
| leave us alone, Marty. RubyCentral most definitely does NOT
| represent "the community". The original guys who wrote rubygems
| - now these were community folks, not some corporate ponicorns.
| Sadly when money is tight, bad things happen, and the ruby
| ecosystem showed this beautifully. Kind of bad too because it
| means money wins over community; but this is a chicken-egg
| problem, because how to grow a community if the trend goes
| downwards, for whatever the reason(s)?
|
| > And I find that most gems follow a similar downward trend of
| activity.
|
| Yup - but this is also old, even before RubyCentral
| transitioned into CorporationCentral. Ruby folks left ruby,
| years ago already. The people I knew from, say, 2005 to 2012 or
| so, also from IRC - some still use ruby, but most moved on to
| other things (also for financial reasons usually).
|
| > Rails on the other hand actually seems to be picking up steam
| and has been remarkably consistent since the big "boom" of
| Rails 3.0 in 2010
|
| Nope. Rails is also dying. It does not have the same 1:1
| problem as ruby has, but the decline is 100% there too.
|
| > Rails is a rare example of an OSS project that's grown into
| its release cadence rather than burning out.
|
| Not really. Ignore the promo. Look at the facts. Rails has been
| hurting too (which makes DHH laughing about when RubyCentral
| mass-purges developers both evil and silly, because that hurts
| the whole ruby ecosystem too - what was shopify thinking
| here?).
|
| > Whether it can still find an audience amongst new developers
| is an open question
|
| Yeah that is the question. Unfortunately the answer is there:
| new developers won't use ruby for the most part. AI also
| competes here now.
|
| 2026 is not like 2006, sorry folks.
|
| > I probably could eventually build things almost as fast in
| another language or framework, but I doubt I'd be smiling as
| much while I did so.
|
| Well, I used perl, php, python (still use python too). Ruby is
| more efficient for my brain though. And I disagree that I could
| be as fast as in another language. I simply have fewer barriers
| when writing ruby for the most part. Less restrictions. I don't
| think anyone thinks ruby itself is a bad language at all. We
| need to keep the discussions separate.
|
| Pretty good comment from Mark Dastmalchi-Round by the way.
| Well-written, tons of details, opinions - even if I may
| disagree with some points, the overall quality of his blog
| entry is very good. We should give him very good marks for the
| blog - even more so as it is not on medium.com. I hate
| medium.com (and the link above, is to medium.com ... why did I
| link it ...)
| leke wrote:
| 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.
| itsthecourier wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| systems_glitch wrote:
| 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 wrote:
| > sometimes it's worth doing things just for the sheer hell of
| it.
| desireco42 wrote:
| 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 wrote:
| 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 wrote:
| just don't
| fixxation92 wrote:
| "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 ;-)
| ergocoder wrote:
| 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.
___________________________________________________________________
(page generated 2026-03-12 23:01 UTC)