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.

▲

pizza234 3 hours ago | parent | next [-]

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.

▲

jonathaneunice 5 hours ago | parent | prev | next [-]

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.

▲

shevy-java 4 hours ago | parent [-]

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. :)

	▲	zem 3 hours ago \| parent [-]
		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.

▲

skipants 4 hours ago | parent | prev | next [-]

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.

▲

shevy-java 4 hours ago | parent | prev | next [-]

Completely agree with you.

For some reason some people want to slap down types onto EVERY language. I call them the type-o-maniacs.

▲

vidarh 3 days ago | parent | prev [-]

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.

	▲	shevy-java 4 hours ago \| parent [-]
		In fairness: RBS sucks though. This one here is a bit better than RBS.