Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Returning to Rails in 2026

markround.com

Post reply on HN
Print view View original

191–200 of 254 posts

Re: Returning to Rails in 2026

#191

Post by aarestad »

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?

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.

Re: Returning to Rails in 2026

#192

Post by bryanlarsen »

tomnipotent wrote: post #180
bryanlarsen wrote: post #123

Earlier quoted context omitted.

Not much work every few months turns into a lot over years, especially if you skip a few of those "every few months" events.

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

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

Re: Returning to Rails in 2026

#193

Post by Salgat »

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.

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

Re: Returning to Rails in 2026

#194

Post by fixxation92 »

"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 ;-)

Re: Returning to Rails in 2026

#195

Post by 42069party »

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…

[dead]

Re: Returning to Rails in 2026

#196

Post by slopinthebag »

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…

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.

Re: Returning to Rails in 2026

#198

Post by x0x0 »

bartread wrote: post #187
oorza wrote: post #83

Earlier quoted context omitted.

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

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

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

Re: Returning to Rails in 2026

#199

Post by draw_down »

vidarh wrote: post #145
draw_down wrote: post #116

Earlier quoted context omitted.

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…

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

[dead]

Re: Returning to Rails in 2026

#200

Post by array_key_first »

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.

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.
Post reply on HN