The article's use of "typed vs untypes" instead of "statically vs dynamically typed" is really unfortunate, and doesn't exactly inspire confidence.
You mean because the word "untype" is a negation and as such doesn't evoke a positive tune?
RBS, Ruby’s new type signature language
91–100 of 340 posts
Re: RBS, Ruby’s new type signature language
#92I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…
You might be correct.
There have been attempts to have types outside the main source or in comments for many dynamically typed languages. They seem to fail due bad programming ergonomics, as maintaining separate "header" files is cumbersome (hello C my old friend).
Re: RBS, Ruby’s new type signature language
#93Earlier quoted context omitted.
I much prefer separate files for type declarations. Or at least the ability to define them separately. Type annotation takes away from readability. I like keeping the types and code separate.
The upside of external files is pure incremental implementation that touches no other tooling and requires no buy-in. I don't see how having to switch files to know that `input` is a `User` increases readability, though. It seems like straight-forward impl-simplicity trade-off, not one of user ergonomics.
Separating type definitions from code can be considered as contributing to readability of idiomatic Ruby on one hand, and type definitions on the other, taken separately on their own—by not imposing constraints on either syntax.
IDEs will likely be able to seamlessly peek/go to RBS type definition on any Ruby identifier in any case.
Re: RBS, Ruby’s new type signature language
#94I'm not thrilled about the separate files with the type information but I completely understand why they did it, and if it were my choice I might make the same one. I don't like the comparison with TypeScript `.d.ts` files however, because TS still lets you do types inline in the code. I haven't seen it mentioned anywhere that this won't be supported by Ruby 3. Does anybody know if Ruby 3 will also support inline typ…
I much prefer separate files for type declarations. Or at least the ability to define them separately. Type annotation takes away from readability. I like keeping the types and code separate.
> Type annotation takes away from readability.
Do you mean for Ruby specifically or in general? I've found that it's much easier to (safely, accurately) read, use, and extend e.g. a TypeScript file than its JavaScript counterpart, even when provided with a .d.ts file.
Re: RBS, Ruby’s new type signature language
#95Earlier quoted context omitted.
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.
Re: RBS, Ruby’s new type signature language
#96I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…
This is why I do not like mypy or types in Python other than dataclasses. If I'm going to type the damn thing I better be getting performance ala cython. Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. Ruby would do far better to fix the bloody `and` vs `&&` issue (it should just be `and` and it should work like `&&`) and strings should be immutable by default with a special syntax or method to make them immutable.
But you're absolutely right about the downsides of stuffing types into a different file. I get why Matz did it (he wants to keep Ruby beautiful and types are crufty) but I don't like them in the first place.
Re: RBS, Ruby’s new type signature language
#97I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…
Adding type checking sort of clips the wings of a codebase, but makes it far less magic, and when you're a company the size of Square or Stripe you want as little magic as possible.
Re: RBS, Ruby’s new type signature language
#98Can 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.
Based on the relative smoothness of Ruby version transitions versus Python, I trust Matz’s preference on this implicitly. One good thing about it being external is that you can optionally and experimentally annotate existing code without munging up your source files. At least so long as this is a bleeding edge feature, that separation makes a lot of sense to me. It’ll be a while before anyone can be confident in a pa…
Pretty much. Matz is very sensitive to breaking the language in any way with the Ruby 3 upgrade, which brought up the true keyword argument hard-break and [likely got that pushed back](https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argume...).
RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons.
While I don't 100% agree with them I have faith that Matz and the team make the decisions they do based on impact and what they see in the community.
Re: RBS, Ruby’s new type signature language
#99I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…
I think it's moderately clear that they're not intending this be a complete solution to type checking in Ruby, but rather a starting point that the community can build on top of.
For instance, I can imagine adding something like comment blocks to Ruby code that RBS tooling can find and treat like the RBS files.
Re: RBS, Ruby’s new type signature language
#100I'm really puzzled by the decision to use a separate file for this. The stated justification ("it doesn't require changing Ruby code") doesn't make sense, and my personal experience with languages with external type specifications is strongly negative. It's an unbelievable pain to keep multiple interface files in sync over time. `.h` files are not something to emulate! External interfaces should be generated by tools…
FWIW, you can use inline syntax with Sorbet[0], one of the two typecheckers that will work with the RBS format (the other being Steep, which does not have inline syntax).
Here's a full example, complete with a typo, based on the example in the blog post: https://bit.ly/3hMEMSp
Here's a truncated excerpt to get the basic idea across:
# typed: true
class Merchant
extend T::Sig
sig {returns(String)}
attr_reader :name
sig {returns(T::Array[Employee])}
attr_reader :employees
sig {params(token: String, name: String).void}
def initialize(token, name)
@token = token
@name = name
end
end