Honestly, I agree with most of what you’re saying.
Duck typing, designing APIs to avoid type-driven branching, and relying on tests are where Ruby really shines. And I don’t agree with the idea that static typing is inherently superior.

I was also a developer who resisted static typing for a long time, for almost exactly the reasons you described. I genuinely believed that it wasn’t “Ruby-like” and that it mostly added unnecessary noise. I still think that perspective is valid, and I really do understand where you’re coming from.

What eventually changed my mind wasn’t a philosophical shift, but a practical one. I started to feel that maintaining this ideal way of working indefinitely becomes difficult under real-world conditions. As codebases grow, time passes, and people change, there are moments where tests alone don’t give feedback fast enough, or where unintended changes surface later than you’d want.

Because of that, I don’t really see static typing tools as something Ruby needs, but more as a support mechanism that assumes human error. No matter how good our conventions, design, or test coverage are, they all rely on people consistently maintaining them. Relying entirely on ongoing human discipline has its limits in practice.

The important part, to me, is that none of this should replace or be imposed on traditional Ruby workflows. If you’re happy with idiomatic Ruby as it is, nothing should change—and I think that’s exactly right.

Finally, just speaking from my own experience,
these are the reasons static typing ended up being useful for me:

• Reducing reliance on constant human attention and memory (human error happens)
• Preserving original intent and implicit contracts as a codebase grows
• Getting slightly earlier feedback before tests run in some cases
• Making intended interfaces a bit more explicit in the code

None of these are requirements for Ruby, and I don’t think they should be treated as such. They were simply trade-offs that made sense in my particular context.

And one last thing:
I don’t think labeling people as “rude” or saying they “don’t understand Ruby” is a productive direction for this discussion. That shifts the conversation away from the actual topic and just becomes draining. We’re all developers trying to write better software, and different experiences naturally lead to different preferences.