RBS, Ruby’s new type signature language • Hacker News Board

Re: RBS, Ruby’s new type signature language

#301

Post by regularfry » Thu, Jul 30, 2020, 9:54 AM UTC

hrktb wrote: post #171

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…

I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters. I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.

I genuinely think that adding `:` as a hash separator was a mistake. Apart from anything else, you get this weird effect where the type of the key in `{"foo": bar}` isn't what you think it is.

Re: RBS, Ruby’s new type signature language

#302

Post by d3nj4l » Thu, Jul 30, 2020, 9:55 AM UTC

Lio wrote: post #285

d3nj4l wrote: post #274

Earlier quoted context omitted.

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.

It doesn't do typechecks, no. You can use solargraph (https://github.com/castwide/solargraph) for that.

Re: RBS, Ruby’s new type signature language

#303

Post by d3nj4l » Thu, Jul 30, 2020, 10:05 AM UTC

transfire wrote: post #289

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…

As soon as I feel comfortable maintaining a Crystal server in production I think I'll switch to it. Last I tried it, things broke and shards required some effort to maintain every version update. I'm eagerly looking forward to their 1.0 and hoping they stabilize a lot more.

Re: RBS, Ruby’s new type signature language

#304

Post by xmdx » Thu, Jul 30, 2020, 10:29 AM UTC

I guess this is just the foundation. A way to check types before runtime. I can see a lot gems making this experience better so I'm not too worried about that. It will become better, and it is optional.

For the time being I think this kind of type checking is only worthwhile in big projects, for smaller projects I have found Sorbet never finds an error, so it's just extra work to generate the files on a big change.

Re: RBS, Ruby’s new type signature language

#305

Post by Vanit » Thu, Jul 30, 2020, 10:34 AM UTC

> Untyped languages allow for rapid development

Citation needed. In my experience this is a fallacy; types take no time at all to write and significantly reduces bugs (Typescript).

Re: RBS, Ruby’s new type signature language

#306

Post by mumblemumble » Thu, Jul 30, 2020, 11:44 AM UTC

dependenttypes wrote: post #281

mumblemumble wrote: post #239

Earlier quoted context omitted.

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?

I'd consider JavaScript to be more toward the weak typing end of things, because it does lots of automatic conversions with surprising results. (see, for example, Gary Bernhardt's "Wat?" lightning talk.) I don't think I'd consider it as weak as C, which has things like unions and pointers that let you just sort of fall out of the type system entirely.

I'd consider Python to be more strongly typed than JavaScript. It doesn't do quite so many automatic conversions. For example, in Python, `1 + "foo"` is a TypeError. In JavaScript, it's "1foo". Sadly, `1 == True` in Python, so it certainly doesn't get full marks.

Re: RBS, Ruby’s new type signature language

#307

Post by MaxBarraclough » Thu, Jul 30, 2020, 12:01 PM UTC

vidarh wrote: post #293

iso8859-1 wrote: post #237

Earlier quoted context omitted.

But when you have things like "duck typing", don't you think "they check types at runtime" becomes less meaningful? The majority of functions written in Python, even the ones that have type annotations, do not effectively have "assert isinstance(...)" in the program text below their signature, which is what I'd expect after reading "check types at runtime". Also, Python now has (in its stdlib!) things like typing.Pro…

I don't really know what you're trying to say here. Why would it be less meaningful to say types are checked at runtime with ducktyping? The nature of ducktyping is that the specific class of an object does not matter relative to behaviour, but a class is not entirely equivalent to a type. If I need an object that implements method `foo`, and don't care about class, then "objects that implements foo" is in itself a t…

Quibbles with your final paragraph: that's not what strongly typed means. It refers to when a language has strict rules restricting implicit type conversions. [0] Also, C++ has RTTI.

[0] https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

Re: RBS, Ruby’s new type signature language

#308

Post by vidarh » Thu, Jul 30, 2020, 12:56 PM UTC

MaxBarraclough wrote: post #307

vidarh wrote: post #293

Earlier quoted context omitted.

I don't really know what you're trying to say here. Why would it be less meaningful to say types are checked at runtime with ducktyping? The nature of ducktyping is that the specific class of an object does not matter relative to behaviour, but a class is not entirely equivalent to a type. If I need an object that implements method `foo`, and don't care about class, then "objects that implements foo" is in itself a t…

Quibbles with your final paragraph: that's not what strongly typed means. It refers to when a language has strict rules restricting implicit type conversions. [0] Also, C++ has RTTI. [0] https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

It's not that simple. There's no uniform definition of strong. You're right strong typing is often used to refer to absence of (or restrictions to) implicit type conversions, but it has also since the beginning been used to reference languages that does not prevent obscuring the identity of the type of an object.

E.g. Liskov and Zilles [1] defined it this way for example:

"whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."

Under this definition C and C++ fails hard, since you can statically cast a pointer to an object and pass it to a function expecting a totally incompatible type.

Note that the system described relied at least partly on dynamic/runtime type checks (in case it reads as if the quote above suggests they used "strong" to refer to static typing):

"It is desirable to do compile-time type checking, since type errors are detected as early as possible. Because of the freedom with which types can be used in the language, however, it is not clear how complete the compile time type checking can be. Therefore, the design of the language is based on a runtime type checking mechanism which is augmented by as much compile-time checking as is possible. "

[1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13...

Re: RBS, Ruby’s new type signature language

#309

Post by jolux » Thu, Jul 30, 2020, 12:59 PM UTC

mumblemumble wrote: post #306

dependenttypes wrote: post #281

Earlier quoted context omitted.

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?

I'd consider JavaScript to be more toward the weak typing end of things, because it does lots of automatic conversions with surprising results. (see, for example, Gary Bernhardt's "Wat?" lightning talk.) I don't think I'd consider it as weak as C, which has things like unions and pointers that let you just sort of fall out of the type system entirely. I'd consider Python to be more strongly typed than JavaScript. It…

Examples like the last one about Python are why I think it’s approximately meaningless as a descriptor. I don’t see why dynamic languages should have any implicit conversions at all.

Re: RBS, Ruby’s new type signature language

#310

Post by Thaxll » Thu, Jul 30, 2020, 1:18 PM UTC

kgraves wrote: post #211

Thaxll wrote: post #138

Earlier quoted context omitted.

The current state of Crystal is basically a language for PoC during the week-end, it's far from being ready. I could go on about what's wrong with the language but: It's not stable, API change all the time, breaking change all the time, cryptic errors, lot of missing basic features, IDE integration etc ...

> The current state of Crystal is basically a language for PoC during the week-end, it's far from being ready. That is changing, earlier this year, the Crystal team are working on getting the language stable for 1.0 [0] Companies are already now using Crystal in production, most recently Nikola Motor Company [1]. Surely they wouldn't choose crystal if it was a 'half baked' language. [0] https://crystal-lang.org/2020/…

You will always find someone somewhere picking up a language / framework and thinking it's production ready, from my experience Crystal is not ready and in the example you gave there is absolutly no reason to no use Rust. They needed C binding, and the fact that they started using Crystal years ago when the state was even worse is very worrisom.