Comment by zem

14 hours ago

the overall field is known as "gradual typing", and it is an attempt to combine some of the benefits of both static and dynamic typing (or to put it more accurately, to explore more of the benefits and tradeoffs on the static to dynamic spectrum). in the "type checkers for ruby/python/js" part of the spectrum what you are trying to ask is "how much static type safety can I add without giving up the power of the dynamic bits", so for instance you have code that generates classes as runtime (not really compatible with a strictly static type system in the most general case), but specific very common uses of code generation, like python's dataclasses, have support within the type checker.

That still has not really explained why they (those who propose that) need types in ruby specifically. Whether python has it or not is not relevant because it is another language. The argument that "language xyz has it, so ruby needs it", can be compelling, but does not necessarily have to be compelling. It needs to have a use case for ruby in and by itself. I don't see that intrinsic use case.

  • I work in Ruby a lot on large/old projects. I think the main reasons are: people nowadays are very dependent on editor intellisense, and "undefined method ... for nil" errors in production are very frustrating.

    That said, I am actually in the "don't want types in Ruby" camp. Intellisense isn't as needed if you're good at using irb (the repl). And the dynamism makes it super easy to write unit tests, which can give you back a lot of the guarantees you'd otherwise get from static types. Most importantly, a lot of the fun in Ruby comes from the ability to make nice DSLs and aggressively metaprogram boilerplate away.

  • the argument is not "some other language has it so we should", the argument is "static type checking is very useful even if it is not 100% strict, and ruby's lack of syntactic support for type annotations makes them clunky to use, so here's an enhancement that adds them".

    the intrinsic use case is that your code is often implicitly statically typed, even if the language itself doesn't enforce that, so it's nice for tools to check it for you. this gets more and more useful the larger your codebase gets; python and javascript have shown that in practice.

    and note that people have already written type checkers for ruby, they are just much less pleasant to use because there is no nice way to express the types you would like to check/enforce.