Comfort, speed, preference, flexibility, lack of benefit on web projects where all data is by default a string, your ORM has already mapped the types directly in the database and will transform everything automatically without repeat definition, you're dealing with a lot of JSON API calls that may change where you don't _need_ all of the data so being forced into a situation of strictly typing 3rd party nested substructures can created a lot of wasted time...

Just off the top of my head. To each their own.

I like Ruby! Ruby has types. They just aren't enforced by a compiler.

Well, yeah, then what's the point?

You can use a static analysis tool to check Ruby types ahead of time (still not a compiler) or provide information for tooling.

Alternatively you use them at runtime to check the correctness of data, which I don't think you can usually do with say Typescript where the typing information is for the most part compiled away[1].

1. I may be out of date on this but when I last looked at runtimes that could take Typescript directly they just threw the typing away. You just didn't need to use the tsc compiler first.

> use a static analysis tool to check Ruby types ahead of time (still not a compiler)

I'll have to check out typeprof and sorbet.

I'm OK not using a compiler. Used one for years and am good on that for now. I like writing Ruby.