Mixed feelings here. Type annotations are a thing Ruby lacks, that other languages have, that I like using in other languages. Ergo, I'd like to have them in Ruby, right?
My knee-jerk reaction is "yes I'd like that" but when I pause to think about how I actually write Ruby code... hmm. I tend to use Ruby when its flexible syntax and type system are helpful. How much would I actually benefit from something that restricts the flexibility of the type system?
Bear in mind, I'm not a "Ruby dev" per se. It's a well-loved tool in my mostly firmware-focused repetoire. I use it for little CLI tools, and toy game engines too (mri embeds into C really cleanly). Fun little things that most folks would use Python for, I just like Ruby better.
I had exactly this reaction when gradual typing came to Python. "Do we really need this??"
But over time, I've grown to love it. Programming is communication—not just with the machine, but with other developers and/or future me. Communicating what types are expected, what types are delivered, and doing so in a natural, inline, graceful way? Feels a big win.
But you use types not to communicate with other people - you use them to give more hints to the python interpreter. Otherwise you could use comments. :)
type annotations in python are essentially structured comments with special syntactic support and runtime introspection facilities (i.e. you can get at the annotations from within the code). they are explicitly not "types" as far as the interpreter is concerned, you can say e.g. `x: str = 42` and python will be fine with it. the value comes from tooling like type checkers and LSPs that work with the annotations, and from metaprogramming libraries like dataclasses and pydantic that introspect them at runtime and use them to create classes etc.
Sure you could just use in-program comments and/or external annotation files. There were a handful of standards for doing exactly that... NumPy, Google, RST/Sphinx, Epydoc, Zope, ...probably a few others I'm forgetting. And there were external "stub" definition files like `.pyi`. Not exactly code, but closely-linked metadata. Ruby seems to be trying something like that with its `.rbs` files.
IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.
You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!
But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.
I think you're 110% on the nose. Types in Ruby really depends on the use-case. I don't think your use cases fit the bill and types would be annoying if anything.
I work on big Ruby on Rails monoliths and I curse every day that I don't have types to work with. It's almost a requirement for large refactors.
This sentiment reflect the type of project worked on - small ones. As projects get bigger, more type information gets lost, and that's why it needs to be compensated, typically via automated (unit) testing.
After having worked with gradual typing, unless the application is very disciplined, IMO automated testing is not enough to document the code, as Ruby makes it very easy to use flexible data structures which very easily become messy.
Ruby has had "officiak" type annotations since 3.0.0 via RBS.
Exactly because of the concerns you described, RBS originally used only separate files for the type annotations, so it can be selectively and gradually applied. You can add Ruby signatures inline as comments as well, but frankly both options looks ugly, and so does many of the alternatives like Sorbet signatures.
My knee-jerk reaction is "yes I'd like that" but when I pause to think about how I actually write Ruby code... hmm. I tend to use Ruby when its flexible syntax and type system are helpful. How much would I actually benefit from something that restricts the flexibility of the type system?
Bear in mind, I'm not a "Ruby dev" per se. It's a well-loved tool in my mostly firmware-focused repetoire. I use it for little CLI tools, and toy game engines too (mri embeds into C really cleanly). Fun little things that most folks would use Python for, I just like Ruby better.