RBS, Ruby’s new type signature language

I absolutely hate this.

Separate files for types with no inline annotations possible? What an embarrassing compromise. This is all because Matz explicitly won't allow type signatures in .rb files. I wonder how long it'll be until a hostile fork if he doesn't change his mind.

I wouldn’t call it “embarrassing.” What is the actual benefit of having inline type annotations? What is the actual downside of having them in a separate file?

If we're going to add type signatures to code, having them visible alongside their definition site is a sizeable part of the value; and, littering directories with doubled files feels suboptimal to say the least. The comparison to typescript in the article isn't really fair, since typescript supports both modes of operation - projects can choose which they'd like to use.

The benefit is being able to see what type a variable is without having to open a separate file. Having an option to also have them in a separate file (ala TypeScript) is perfectly fine

If you can't calmly go "ah, I see why they did X, but I would prefer if they did Y," I think the problem is only on your end. Let's be adults/engineers.

I've found that if all you can say is "I hate this", you usually don't actually understand the trade-offs.

In the meantime, you have Sorbet available. What's the problem?

Adults and engineers both hate things sometimes (tone policing, for example).

Both sorbet and RBS have put huge amounts of effort into bolting type systems onto ruby in ways that don't run afoul of Matz's categorical and in-principle rejection of adding type-annotation syntax to the core language. Both or either of these projects would have much better ergonomics without having to bend to this constraint.

As ruby's user base skews further and further away from the hobbyist market and toward the startups that began in the period when ruby was 'cool' that have now grown up into enterprises, this pressure will continue. If Matz doesn't recant, the two possible futures are:

1. Deep compromise (see Sorbet, RBS) to keep types out of the core language; or

2. A hard fork, or a one-level-up language like typescript.

How hard is it to imagine that you need to keep 2 files in sync, and that you can't type anything inside a method.

I was even hoping to use ruby as a main language having used it before but I'm about to lose any interest in the language when its reality is a bit decoupled from the rest of the world.

Have you ever worked with a language that has header files (C/C++) or a language that can use them optionally (Ocaml)? In practice, keeping the files in sync isn’t difficult. In fact, it ends up being better (for me) in terms of readability, because I can look up the type definitions in one place, store them as context, and then read code that isn’t littered with type annotations. Type annotations add quite a bit of noise to code. I think that’s what Matz is going for here. You need to be able to keep the readability of Ruby, which he’s dedicated his life to.

Not to anecdote too hard, but the practice of doing type signatures out-of-line that you are describing is my absolute least favorite part of OCaml, which is otherwise a very lovely language. As for C++, it has enough other stuff going on that I probably can't say the header files are my least favorite feature, but they certainly don't make life easy. I think it makes sense to challenge that decision from an ergonomics standpoint, even if it makes sense within the constraints the Ruby core team has decided upon.

I very much like Ocaml signature files. Jane street recommends using them, as an example. There’s no other way to communicate the high level contract of a module. With type signatures that are in line with the code, the high level contract gets lost.

Type info on hover in your editor gives you that.