Returning to Rails in 2026 • Hacker News Board

Re: Returning to Rails in 2026

#201

Post by chuckadams » Thu, Mar 12, 2026, 5:44 PM UTC

apsurd wrote: post #21

slopinthebag wrote: post #14

Earlier quoted context omitted.

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.

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…

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.

Re: Returning to Rails in 2026

#202

Post by vidarh » Thu, Mar 12, 2026, 6:17 PM UTC

draw_down wrote: post #116

sensanaty wrote: post #110

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

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

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/

Re: Returning to Rails in 2026

#203

Post by mike_ivanov » Thu, Mar 12, 2026, 6:23 PM UTC

eudamoniac wrote: post #181

sensanaty wrote: post #110

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

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

Ruby is a strongly typed language. I think you are confusing strong typing with static typing.

Re: Returning to Rails in 2026

#204

Post by Larrikin » Thu, Mar 12, 2026, 6:32 PM UTC

mattsears wrote: post #169

sensanaty wrote: post #110

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

What is it about large untyped codebases that make it a nightmare?

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.

Re: Returning to Rails in 2026

#205

Post by blandflakes » Thu, Mar 12, 2026, 6:57 PM UTC

lowenbjer wrote: post #166

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 buildin…

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

Re: Returning to Rails in 2026

#206

Post by coffeefirst » Thu, Mar 12, 2026, 7:06 PM UTC

f311a wrote: post #37

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

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.

Re: Returning to Rails in 2026

#207

Post by apsurd » Thu, Mar 12, 2026, 7:21 PM UTC

slopinthebag wrote: post #196

apsurd wrote: post #21

Earlier quoted context omitted.

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…

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.

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.

Re: Returning to Rails in 2026

#208

Post by weavejester » Thu, Mar 12, 2026, 8:07 PM UTC

fourseventy wrote: post #179

mattsears wrote: post #169

Earlier quoted context omitted.

What is it about large untyped codebases that make it a nightmare?

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.

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.

Re: Returning to Rails in 2026

#209

Post by schlch » Thu, Mar 12, 2026, 8:49 PM UTC

eudamoniac wrote: post #181

sensanaty wrote: post #110

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

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

I still really like rails. It’s really fun until your codebase reaches a certain size. At that point you better have a large suite of test which becomes a problem of it self because the tests will take forever to complete.

I tried sorbet a couple of times and totally get why it’s useful but imo it’s not just lacking (e.g. compared with what can be done with TS or even a simple type system like golang) but it also removes all the fun parts of ruby / rails.

Re: Returning to Rails in 2026

#210

Post by goatlover » Thu, Mar 12, 2026, 9:25 PM UTC

Salgat wrote: post #193

fourseventy wrote: post #179

Earlier quoted context omitted.

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.

The best perspective I've seen is that statically typed enforcement is basically a unit test done at compile time.

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.