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

281–290 of 340 posts

Re: RBS, Ruby’s new type signature language

#281

Post by dependenttypes »

mumblemumble wrote: post #239
jolux wrote: post #235

Earlier quoted context omitted.

I have tried programming in Clojure :) I just prefer strongly typed languages.

Clojure is strongly typed. I think you mean statically typed. They're orthogonal concerns. C is statically and weakly typed. Clojure is dynamically and strongly typed. PHP is dynamically and weakly typed. Haskell is statically and strongly typed. Java, as the most design-by-committe language ever, manages to be a mix of all four.

Strong typing generally does not mean much and everyone seems to be using a different definition. Would you consider Javascript weakly typed? What about Python?

Re: RBS, Ruby’s new type signature language

#282

Post by bad_user »

avolcano wrote: post #9

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

Flow supports importing type definitions for third party untyped libs. And in fact did a better job at being integrated in current projects.

Flow lost because the compiler was in really bad shape, slow and frequently crashing. Also their equivalent repository to DefinitelyTyped would ignore PRs for months and years and afaik still does.

It's like it was somebody's toy project and its author eventually lost interest.

It's a pitty because TypeScript still has unsound generics. But Microsoft know how to make dev tools and maintain them.

Re: RBS, Ruby’s new type signature language

#283

Post by jbritton »

jolux wrote: post #242
mumblemumble wrote: post #236

Earlier quoted context omitted.

Sorry if I wasn't being clear. I'm not saying that's the only way it can work in static languages. I'm saying that that's the way it tends to work out in practice, because the ergonomics of most popular static languages tend to discourage a less brittle approach. Whereas the ergonomics of popular dynamic languages tend to favor an approach that I find, for this specific purpose, to be both less verbose and more robus…

What is the difference in approach between these? I've programmed extensively in dynamic and static languages, and don't understand what you're talking about. Less verbose, I might concede. More robust though, I need some more evidence.

Reminds me of Rich Hickey’s “Maybe Not” speech, which I understand him suggesting that programming with “sets” is better than programming with “records” that may contain optional values.

Re: RBS, Ruby’s new type signature language

#284

Post by jbritton »

mumblemumble wrote: post #239
jolux wrote: post #235

Earlier quoted context omitted.

I have tried programming in Clojure :) I just prefer strongly typed languages.

Clojure is strongly typed. I think you mean statically typed. They're orthogonal concerns. C is statically and weakly typed. Clojure is dynamically and strongly typed. PHP is dynamically and weakly typed. Haskell is statically and strongly typed. Java, as the most design-by-committe language ever, manages to be a mix of all four.

Weak typing is when types get automatically transformed like 2 + “3” == 5, “2” + 3 == “23”. Strong typing doesn’t do these types of automatic conversions and throws exceptions or generates a compiler error.

Static typing — types checked at compile time. Dynamic typing — types checked at runtime.

Re: RBS, Ruby’s new type signature language

#285

Post by Lio »

d3nj4l wrote: post #274
derwiki wrote: post #249

Earlier quoted context omitted.

RubyMine tries but it certainly works less well than PyCharm and GoLand.

RubyMine works great if you add yard type docs to your code.

Is it checking those types or just reporting then?

I’ve seen so many instances where yard doc has the wrong return type or misses a return type that I rarely trust it.

Re: RBS, Ruby’s new type signature language

#286

Post by Lio »

jrochkind1 wrote: post #205
rattray wrote: post #198

Earlier quoted context omitted.

> why not just modify the ruby syntax The Ruby syntax is too complicated to allow for changes like this to be backwards-compatible. For example, `attr_reader token: String` is valid ruby today – that's the same as `attr_reader(:token => String)` which somebody might be doing in the wild, since you can override `def self.attr_reader`. Similarly, `def initialize(token: String` clashes with the definition of keyword arg…

doh! good point. I am not able to spin that into "And besides it's better to force it to be in two files anyway!", I don't think it is, but I guess it's not so easy to do different.

If we could write tests in .rbs files it would more naturally fit into existing 2 file workflows.

Mind you, if we could write tests in .rbs then I guess .rbs could form the basis of a new ruby syntax without breaking compatibility with old code in .rb files.

Re: RBS, Ruby’s new type signature language

#287

Post by avodonosov »

dragonwriter wrote: post #221
avodonosov wrote: post #197

Earlier quoted context omitted.

It must be a very easy next step to allow type declaration inline with the code, for example as comments of special format, or maybe some meta-fields / annotations (I'm not a rubyist so don't know whether the language allows associating custom meta information with program elements).

> It must be a very easy next step to allow type declaration inline with the code Updating Ruby’s already notoriously complex syntax to support type annotations while keeping existing Ruby code valid with it's existing semantics is...not a very easy step, I suspect. Annotations in documentation is a more viable way of integrating type definitions into program source files.

I did not suggest to update ruby syntax

Re: RBS, Ruby’s new type signature language

#288

Post by nurettin »

chillfox wrote: post #176
rudolph9 wrote: post #163

Earlier quoted context omitted.

Haven't used ruby in years for the typical reasons people move away from it (performance, strong types, GVL, etc.) but syntax is #1 reason I like programming in Ruby. I did mostly ruby for about 5 years and really grew to love it! It may seem bonkers at first but quite enjoyable once you understand it. Now nearly 4 years later of mostly javascript, golang, python, haskell I still regularly stop and think to my self h…

Crystal [1] is a pretty nice ruby like language with types and it is up there with Go/Rust for runtime performance. [1] https://crystal-lang.org/

Crystal is nice since they added a decent concurrency model, but it doesn't support one of the major platforms (windows)

Re: RBS, Ruby’s new type signature language

#289

Post by transfire »

castwide wrote: post #257

I'm still trying to make sense of this announcement. With a lack of type annotation in the Ruby core, I chose to build off YARD to make gradual type safety work. Now I don't know if there will be a standard that supports type safety or if I should continue down the path I'm already following. Help me, Ruby core developers. You're my only hope. (edit: I should have explained that I'm talking about the type checking fe…

I hear you. It occurred to me that Ruby could have chosen to innovate with something like a Semantic TomDoc. To choose a separate file based approach seems like a step backward. At the very least it could have been module based. But Matz is a C coder -- not a Ruby coder. So it doesn't necessarily surprise me.

It's sad though. Since poor design of Refinements, C transpiling for 3x project, and now this, I am less and less inclined to continue using Ruby. I miss some of the dynamics but I find myself using Crystal instead.

(Honestly, if any one figured out a way to supplement Crystal with dynamic behavior for those features that a static language can't offer, Ruby would be done.)

Post reply on HN