RBS, Ruby’s new type signature language

Can someone explain why the types cannot live in Ruby code itself (after an appropriate version bump)?

Python 3 incorporated types into the language itself, in a similar way (though non-reified) to PHP. This seems much easier to deal with than requiring two files (.rb and .rbs) to describe a single data structure.

Because Matz won't let people add type annotations to the ruby grammar.

Which is great.

Yeah, it is.

I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app. It's mostly a documentation system. And it slows development down.

Especially in Ruby which is such an elegant "programmer's language" I think it would just be silly.

A-fucking-men.

In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs.

Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics.

If you want strong typing, then good for you. Just pick a language that fits that mold.

So much of what I love about Ruby is what it doesn't make me do.

> Type issues are about 0% of my Ruby bugs

Doubt.

In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.

Maybe we just work on different kinds of problems.

70%+ of bugs I deal with are business logic issues that no type system could solve.

Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).

I've worked across a wide range of industries over several years, and it's always been pretty similar. You should be building the business constraints into your types so that errors in the business logic become errors in the types - in my experience if you actually work with the type system then most errors become type errors. If you've got examples of the kind of errors you're talking about then I could try to be more specific.

Not the GP, but here is a scenario that I am interested in understanding from the perspective of types.

A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month.

Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78.

We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way.

Is there a way this can be encoded in types? That would be very interesting.

Thanks.