Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

121–130 of 340 posts

Re: RBS, Ruby’s new type signature language

#121

Earlier quoted context omitted.

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…

> It's mostly a documentation system. And it slows development down.

Well, I guess this is also a matter of perspective.

From where I'm standing, I'd rather you slow down and "document" your code. Code written at the speed of thought makes for an awesome MVP and for an awful legacy for your co-workers.

Re: RBS, Ruby’s new type signature language

#122
post #77
post #32

Earlier quoted context omitted.

You don't want to switch to a half baked language for anything serious.

How is Crystal a "half baked language"?

You wouldn't know what edge cases it might have unless the language becomes a "major language" to have more eyes.

I don't think average programmers even know about it.

Re: RBS, Ruby’s new type signature language

#123

Earlier quoted context omitted.

Soutaro is indeed a code member of the Ruby team, he also happens to work at Square. Soutaro is also one of the main contributors to RBS and helped define that standard. He was going to keynote on this at RubyKaigi this year until it was cancelled, and had a talk at RubyConf as well on this.

Thanks for clarifying! It's great that Square is funding work like this.

Yep, and glad to see the work Stripe is doing on things as well. Always enjoy seeing where you all are going.

Soutaro has been great to work with over here (Square), and he has a ton of really amazing things coming soon that we're working on OSS'ing later.

Re: RBS, Ruby’s new type signature language

#124
post #91
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.

You mean because the word "untype" is a negation and as such doesn't evoke a positive tune?

No, because it is wrong.

Ruby is not untyped. It is dynamically and strongly typed.

BCPL is an untyped language. One of very few.

Re: RBS, Ruby’s new type signature language

#125

Earlier quoted context omitted.

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 terr…

The philosophical argument in the Ruby community is basically that Ruby is not a statically typed language, period. And a strong contingent, myself included, do not want a hybrid world where type annotations are optional, spattering redundancies all over our syntax. Mostly because I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking and destroy most of what I love about Ruby.

That's why the approaches being used keep the type annotations out of the source files themselves.

Re: RBS, Ruby’s new type signature language

#126
post #23
post #2

Interesting. 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!

Sorbet's FAQ seems to say otherwise.

https://sorbet.org/docs/faq#when-ruby-3-gets-types-what-will...

> Ruby 3 has no plans to change Ruby’s syntax. To have type annotations for methods live in the same place as the method definition, the only option will be to continue using Sorbet’s method signatures.

Re: RBS, Ruby’s new type signature language

#127
post #16

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.

I wonder what percentage of TypeScript users write their types inline, and what percentage of users choose to write separate .d.ts files for each of their source files.

My guess is the latter is vanishingly small – that it's pretty much only done for libraries that were written before TS was a thing – so I wonder how things will go in Ruby.

Maybe everybody will just standardize on third-party tools like Sorbet which allow inline typedefs, or use types a lot less, or hook up a "regenerate inferred .rbs on save" workflow in their editor, or just switch between files a lot.

Re: RBS, Ruby’s new type signature language

#129
post #5

Types help communicate information to the next developer. They're important, use them!

This isn't just about Types, per se. Ruby has types all over. You can't write Ruby without them.

This is about Static Typing and Type enforcement, in the context of a language that holds flexibility and meta-programming as high values.

Re: RBS, Ruby’s new type signature language

#130

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

Treating it as a starting point is, I think, the best justification for putting them in separate files. I don't quite like the idea of having them in separate files, but at least that way replacing it or evolving it without breaking peoples code-bases will be easier.
Post reply on HN