[ekidd]

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails.

But as of couple of years ago, Rails came with a number of drawbacks:

1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/ruby/comments/105sdax/whats_the_lat... for a discussion.

2. The lack of static typing meant far less IDE support. Fewer documentation tooltips, less autocompletion, etc.

3. I used to do a lot of Rails consulting. And whenever I had to drop into a codebase with more than 50,000 lines or 5 active developers, it was generally a painful slog. Too many weird Rails plugins that stopped being maintained, too much magic, too many nasty surprises while refactoring.

Basically, smaller Rails projects were an absolute delight. Larger Rails projects, though, tended to feel more like a swamp. Tools like https://activeadmin.info/ could tip the balance where applicable.

I still think that small Rails projects are fantastic, and I don't think anything since has remotely matched Rails' productivity within that niche. There's just too much mature tooling, and much of it works together seamlessly. But not too many projects want classic multi-page apps right now, and small projects often grow up to be big projects.

[axelthegerman]

Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is.

Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code

[ekidd]

I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing:

- A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment.

- The ability to change an API and immediately see all the affected code. This affects refactoring speed when making big cleanups. Massive updates I could do in a few hours in Rust might take 2 weeks on a big Rails project.

- Team-wide clarity on exactly what goes into key data structures. Can something be null? Does it allow numbers, or only strings? Etc.

With two developers and a small code base, you can keep most of this information in your head. And Rails is still unmatched for terse, clear code, plus off-the-shelf modules for many common tasks.

I'm not even sure that Ruby could be retrofitted with a really worthwhile type system, to be honest. JavaScript already required a lot of black magic, and in some ways, Ruby is even more dynamic. So perhaps Ruby is better left as-is, even if that makes it a poorer choice for projects that would benefit from static typing.

[axelthegerman]

Well I don't mind to agree to disagree :)

Similar points between your comment and the other reply. Still I worked with Java in the past and Ruby has been a liberation for me. It allows me to simpler, cleaner and less complex to write my code.

I work on one of the largest Rails apps and the added typing is usually more of a burden than anything - sure could be the implementation of typing which is harder for Ruby than let's say JS (to your point)

Still I don't mind others wanting to write typed code and finding more positives to it than I do - I just still am not convinced that statically typed is ever objectively better than dynamic and it stays of subjective nature.

TLDR: imho the quality problem of most large code bases is not due to dynamic typing but due to many other factors that lead to low quality code

[packetlost]

The pros almost always outweigh the cons these days though for any sizeable project. This may not have been historically true when the performance of IDEs and compilers was worse, but it certainly is true today. I've spent most of my career in dynamic languages but have spent the last year and a half or so strictly in strongly-typed languages. There's a night and day difference in crashes/reliability, refactor-ability, and tooling. Dynamic languages shove all of your validation into runtime where you may or my not be looking when failures occur and refactors are fucking nerve wracking because it's impossible to know if something really doesn't rely on that function or not. Tests can fill this gap, but that's a lot of additional code you now have to write and maintain and refactor and run in your slow af CI pipelines.

[quest88]

I suspect you'd find the same thing if you were a python or php consultant diving into python or php projects.

[alex_lav]

This is correct, but doesn't really change the discussion at all does it?

[quest88]

It does. The parent was making an argument that rails is not great past 1 or 2 developers and more than X lines of code. I was pointing out this argument is not a strong one, since the this is not exclusive to rails, instead hoping to focus on what is exclusive to rails, so we can have a discussion about "Use Rails".

[dbreunig]

A surprising answer to issue 2 is that Copilots are filling in the gap. Rails, VS Code, and Github Copilot work very well. Both for autocomplete and explanation. I expect them to get better as context window size improvements arrive.

[Fire-Dragon-DoL]

One new thing on the table is that AI (github copilot, openai) seems to perform way better on non-statically-typed languages. Anecdotally, the suggestions are way better in ruby than go.

I could guess why, but I'll let others speculate.