[Gigachad]

Rails is extremely easy to get started with but after a few years the lack of types on Ruby cripples every single Rails app I've ever worked on. You can have as many unit tests and browser automation tests as possible, but updating any gem is a dice roll despite doing as much due diligence possible. And it's always something extremely trivial like a method changing its parameters without announcing it in the change log for some reason. Something almost any other language would warn you about.

I've been doing Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks. The only advantage Rails still holds is the out of the box batteries included package. But once a TS framework gets this, Rails will be in decline.

[0xblinq]

> Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks

I think you're comparing a language/runtime with a framework here. I also prefer Node and JavaScript over Ruby but I get what you say, and I agree.

I think Adonisjs ticks all the boxes to be that framework in the future. It just doesn't have the community it needs to be 100% successful yet... with more adoption it will get all the missing features, documentation and little annoyances it might have today polished.

But something I'm worried about is if that the fragmentation is just too big at this point. I don't see people agreeing on a single "full stack" framework as it happened in other environments.

I think this happens because most other "big frameworks" were born when there were not that much competition and not that many people on their ecosystems, so there were a lot fewer options and people concentrated around those frameworks and made them grow to what they are today (Laravel, Rails, Django, Spring...).

The "backend JavaScript" ecosystem is a freaking mess. So many competing options, all of them terribly incomplete, all of them claiming to be "full stack" just because they can execute JavaScript on the server... yes, maybe "full stack" but without the battery... it's a lamborghini that you have to put together yourself before being able to use it.

[mplewis]

This is exactly why I’m keeping my eye on RedwoodJS. They are coming for the crown.

[0xblinq]

Same thing that other people sat about Next.js, about Remix, Nest, Qwik, and the other 10 thousand that "are coming for the crown". In fact, that's the problem.

[favorited]

Doesn't Ruby have 2 production-ready typecheckers now? I think Ruby officially has something called RBS, and Stripe open-sourced Sorbet.

[klardotsh]

Used to work at a Rails shop, and led an effort to get type safety into the codebase. It was a nightmare that wasted endless time and added plenty of stress.

Sorbet is great on vanilla Ruby code that doesn't try to use too much arcane metaprogramming. It's "okay" on vanilla Ruby code that uses some arcane metaprogramming that humans can reliably reflect in RBS files. In a Rails codebase, which is (IMO) a huge ball of relatively hard to statically analyze magic and quite heavily uses all sorts of tricks for either API ergonomics/skimmability or for performance, it was a mess, and frankly, I had a pretty nightmarish time selling almost any of the feature set beyond (1) ADTs/Enums (2) the subset of Interfaces as exposed by `T::Struct`.

Sorbet is a herculean effort by some extremely talented devs. I don't at all want to discredit that. Tapioca is likewise an impressive DSL-reflection machine on top of RBS files, particularly post-0.8 release. But type safety in a Rails app is, at least in my experience, extremely high cost both upfront and maintenance.

[ywain]

To offer another point of view: I work on a recent Rails app that was set up with Sorbet/Tapioca from the get-go. All Ruby code is `# typed: strict`, and we (I) feel like the ROI is generally positive. It's caught more than one bug, and it's easy to eject from it when it gets in your way.

That said, type safety via Sorbet/Tapioca is ultimately an afterthought in Ruby and the DX suffers from it compared to languages where type safety is baked in. In my limited experience, MyPy in Python was even worse though.

As for RBS, I have literally never seen it used in the wild and I don't know why the Ruby core team bothers with it rather than go all-in on Sorbet.

[klardotsh]

(your comment made me realized I kept typing "RBS" when I meant "RBI" in a Sorbet context. oops)

Anyway, I did have my strong suspicions that Sorbet would pay off more in a codebase that used it from Day 1. Glad to hear at least one report that indeed, that was the case.

[Fire-Dragon-DoL]

They are terrible. Typescript might have spoiled me, but the type system is bad and the type checkers are even worse.

[Gigachad]

We evaluated them, it's just not there and it's unclear if it ever will be. DHH, the lead for the Rails project has indicated that Rails will "absolutely not" have a type checker in reply to a tweet asking about it. And a huge amount of work would be required from the Rails team to get type checking to work.

[brightball]

I've worked with a lot of Rails code bases over the last 10 years and just haven't ever experienced this problem from a types perspective.

Certainly, if you let gems start to get out of date the dependency chains to get them updated can become a task but that's fairly true of any language. It's one of the selling points for moving parts of an app to isolated services too.

Everything is a tradeoff though. I don't know that you can get the Aspect Oriented Programming gains that you get with Ruby and Rails with a more strictly typed language.

[Fire-Dragon-DoL]

Every Rails upgrade is kinda proof of the problem, isn't it?

There is an entire market on Google of companies expert in upgrading Rails, that to me is a bad signal.

(notice, I have almost 15 years of experience with rails)

[brightball]

During the Ruby 1.8.7 to 1.9 transition there was a lot of complexity to things, but it hasn't really been a big problem since then has it?

[Fire-Dragon-DoL]

I dodged that, started getting serious with rails 3 and ruby 1.9+

No,there are still many undocumented breaking changes. I recently upgraded an old app from Rail 4 to 7 that used minimal non-rails stuff and was shocked by the corner cases.

Manu changes to activerecord api go completely undocumented, but they break the code nonetheless

[brightball]

Did you go straight from 4 to 7 or 4, 5, 6, 7?

[Fire-Dragon-DoL]

There is no upgrade guide from 4 to 7,so I did from 4.2 to 5,from 5 to 5.1, from 6 to 6.1 and then to 7.

I actually found a bug that broke my app at version 6 that was resolved in 6.1,so technically my tests were not passing in version 6 and I did an "unsafe upgrade" to version 6.1