Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

Post reply on HN
Print view View original

101–110 of 340 posts

Re: RBS, Ruby’s new type signature language

#101

Post by fimbulvetr »

jakearmitage wrote: post #81
burke wrote: post #50

Earlier quoted context omitted.

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

Which is great.

I don't use ruby, I am genuinely interested - why is it great? I'm assuming if it were ever allowed, it would be a use-at-will feature and wouldn't affect anyone who didn't use it. Typescript has probably doubled if not more my speed and accuracy since I've adopted it - yet I still do plenty of things in normal javascript. These days I'm usually unhappy when something does not have typings because it can make it terribly difficult to discover things.

Re: RBS, Ruby’s new type signature language

#102

Post by mekster »

hombre_fatal wrote: post #60
amw-zero wrote: post #49

Earlier 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.

That can be covered by the editor to give the user some hint by referencing the external file but for the user, having have to keep adding it on a separate file seems pretty annoying as you need to keep declarations synched in 2 files.

Also how do you type something in an inline function?

Re: RBS, Ruby’s new type signature language

#103

Post by Jabbles »

baweaver wrote: post #98
skywhopper wrote: post #90

Earlier quoted context omitted.

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. W…

His view is probably informed by the Python 2->3 experience.

Re: RBS, Ruby’s new type signature language

#104

Post by MaxBarraclough »

vidarh wrote: post #86

The article's use of "typed vs untypes" instead of "statically vs dynamically typed" is really unfortunate, and doesn't exactly inspire confidence.

Indeed. To expand on your point: yep, it's incorrect. An untyped language is a language in which there is no concept of type. Assembly languages tend to be untyped. Forth is untyped.

The Ruby and Python languages do have the concept of type, it's just that they're dynamically typed, not statically typed. They check types at runtime.

Re: RBS, Ruby’s new type signature language

#105

Post by mekster »

setpatchaddress wrote: post #52

I'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…

Right. TypeScript also doesn't require changing files and everything is opt in but you can add them inline.

If the author thinks that's the biggest benefit, I'm inclined to think the ruby community doesn't seem to have enough eyes these days in the core development.

Re: RBS, Ruby’s new type signature language

#106

Post by RangerScience »

heavenlyblue wrote: post #65
setpatchaddress wrote: post #52

I'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…

How do you even type local variables?

Why would you need to?

Edit: Like, seriously. Either the local var is populated by something coming in externally (which is then typable) or, unless your code is too complex / large, it should be easy to see everywhere it's used, and then why would you need that additional typing info?

Re: RBS, Ruby’s new type signature language

#107

Post by nicoburns »

swagonomixxx wrote: post #85

I 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 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.

TypeScript has this functionality (in addition to being able to write actually TypeScript files with inline annotations. The big advantage is being able to provide 3rd party type definitions for libraries that don't provide them and aren't interested in using them. This allowed TypeScript to bootstrap decent library support well before it was popular enough that the mainstream was considering adopting it, and this in turn enabled widespread adoption.

> My more existential question is, is there really an advantage to doing static type checking in Ruby? When I was doing Ruby, the way you can change objects on the fly, add methods on the fly, the vast amounts of metaprogramming, are types at "compile" (I know, not really) time really the same as types at runtime?

Again, I think TypeScript shows that there is. Sure, there are times when you want to do super-dyanamic stuff. And you can opt out of type checking using the "any" type in those cases. But a lot of the time you're not doing anything complicated, and you just want a compile-type check that ensures you're passing the correct type to the function you're calling.

Re: RBS, Ruby’s new type signature language

#108

Post by baweaver »

Jabbles wrote: post #103
baweaver wrote: post #98

Earlier quoted context omitted.

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. W…

His view is probably informed by the Python 2->3 experience.

It was, and I was around during one of his discussions on that at RubyConf last year. It's a very valid concern and Matz is very sensitive to it. There are a lot of things he's joked about removing or changing but won't because of those reasons.

If you take a look at his keynote video he says quite a bit on this too.

Re: RBS, Ruby’s new type signature language

#109

Post by rch »

hombre_fatal wrote: post #75
rch wrote: post #42

Earlier quoted context omitted.

> still not there And never will be.

Not sure what you're saying. What are places where Node isn't caught up to Ruby and can never catch up to Ruby? Ruby on Rails seems like a kneejerk response, but then again it doesn't exist because nobody really wants it, not for technical reasons. For example, Python has all the ML/math stuff. Nothing comes to mind for Ruby.

I think the parent comment was referring to the overall market position of RoR, and I'm saying that Node isn't likely to achieve an equivalently dominant share going forward, due at least in part to the wide variety of options available.
Post reply on HN