Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill.
I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.
I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book.
However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't think dynamically typed Ruby is ever going to die. Whether large enterprise codebases will standardize on requiring type signatures is a different matter, because the benefits always outweigh what downsides you see in static typing once you surpass a certain scale.
>Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty.
I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.
My biggest complaints all center around the intersection of custom types with protocols and extensions, especially when trying to get a generic approach to something working.
