It’s a separate RBS file for now, but if/when this gets integrated into Ruby itself how will it interact with the new Ruby 2.7/3.0 keyword argument syntax that also uses the colon? https://bugs.ruby-lang.org/issues/14183
RBS, Ruby’s new type signature language
21–30 of 340 posts
Re: RBS, Ruby’s new type signature language
#22> Typed versus untyped is a 30-year-old issue for programming languages. I'm pretty sure the merits of typed vs untyped has been going on since the 1950s at least. 30 years is such a specific period of time that it makes me wonder what happened in the early 90s that the author is referring to.
Ruby was invented? :)
Re: RBS, Ruby’s new type signature language
#23Interesting. I’m surprised they didn’t opt to do this inline with the rest of the ruby code, because now they can diverge from each other. It’s a bit like a separate header file in C/C++/Obj-C, except in those cases the compiler will yell at you if the implementation doesn’t match the header. Having it blow up at runtime instead doesn’t feel like such a big change from the way it is now, other than helping out IDEs.
After reading the article I'm not sure, but.. it seems reasonable to assume that you can do both. Inline and separate files. The same way TypeScript does it.
Hopefully, anyway!
Re: RBS, Ruby’s new type signature language
#24At some point it makes more sense to switch to Crystal.
Crystal is a non-starter for me since the entire appeal of Ruby is the runtime metaprogramming.
Re: RBS, Ruby’s new type signature language
#25Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as Typ…
For other readers: "Sorbet" refers to https://sorbet.org/ , Stripe's Ruby type checker.
apologies, meant to add that as a link when I referenced Stripe in the first sentence!
Re: RBS, Ruby’s new type signature language
#26Separate ruby header files with type information? Seriously? What's the rational behind that? Is it just to make clear that the ruby interpreter doesn't really care about the type information and doesn't use it to improve the code's performance?
With all due respect, but IMHO this is too little and much too late.
Re: RBS, Ruby’s new type signature language
#27It's worth noting that while the article is coming from Square, this is an official Ruby project and is "Ruby 3’s new language for type signatures".
Re: RBS, Ruby’s new type signature language
#28Separate ruby header files with type information? Seriously? What's the rational behind that? Is it just to make clear that the ruby interpreter doesn't really care about the type information and doesn't use it to improve the code's performance? With all due respect, but IMHO this is too little and much too late.
"The benefit of having different files is it doesn't require changing Ruby code to start type checking. You can opt-in type checking safely without changing any part of your workflow."
Re: RBS, Ruby’s new type signature language
#29Earlier quoted context omitted.
> I’m surprised they didn’t opt to do this inline with the rest of the ruby code, As they mention in the post, they followed typescript's approach, here. The benefit is it allows you to layer in typing into an existing codebase in a non-disruptive way.
But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.
Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.
Re: RBS, Ruby’s new type signature language
#30Separate ruby header files with type information? Seriously? What's the rational behind that? Is it just to make clear that the ruby interpreter doesn't really care about the type information and doesn't use it to improve the code's performance? With all due respect, but IMHO this is too little and much too late.
Isn't this similar to how TypeScript allows annotations for JavaScript to live in separate files? My (possibly naive) assumption is that the goal is to make it easier for developers to write type annotations for projects they use without necessarily having to convince the maintainers to add them to the project itself. I've heard of people using TypeScript annotations from https://definitelytyped.org/ for dependencies which don't have their own annotations.