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

Types will be part of Ruby 3 stdlib source

twitter.com

Post reply on HN
Print view View original

21–30 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#21

Post by inopinatus »

pmontra wrote: post #9
inopinatus wrote: post #5

It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.

Do you have any reference to any documentation of how they implemented types?

The docs say "Every Ruby class and module doubles as a type in Sorbet" and it was explicitly described as a nominal type system in a talk at Strange Loop 2018.

Re: Types will be part of Ruby 3 stdlib source

#22

Post by jaequery »

cocochanel wrote: post #15

Why is everything moving to types?

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

Re: Types will be part of Ruby 3 stdlib source

#24

Post by westoque »

cocochanel wrote: post #15

Why is everything moving to types?

I believe it depends on the use case. If you notice, Stripe and Coinbase are the first few companies that use the type system. They are both dealing with financial systems and numbers in general where having types would help a lot in catching errors and bugs earlier. I've worked on financial systems before in a dynamic language, JavaScript, and from my experience there would be cases where a number would be passed from a place where it's a string (in a textfield) that then needs to be passed around as an integer at times. Type systems would help catch bugs here or in similar situations.

Re: Types will be part of Ruby 3 stdlib source

#25

Post by codesushi42 »

cocochanel wrote: post #15

Why is everything moving to types?

There is benefit to future proofing code with basic static analysis for type checking.

But it is always an incomplete solution because a) old code needs to be retrofitted, see TypeScript's way of defining type maps for vanilla JS or b) more commonly you keep the code around that's using unsafe types, effectively passing void*|Object|"choose your poison" around.

Re: Types will be part of Ruby 3 stdlib source

#26

Post by tomc1985 »

jaequery wrote: post #22
cocochanel wrote: post #15

Why is everything moving to types?

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps?

I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

Re: Types will be part of Ruby 3 stdlib source

#27

Post by eru »

symlinkk wrote: post #18
cocochanel wrote: post #15

Why is everything moving to types?

Because TypeScript has proven that a type system can be helpful without being clunky and annoying.

I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.

Re: Types will be part of Ruby 3 stdlib source

#28

Post by eru »

jaequery wrote: post #22
cocochanel wrote: post #15

Why is everything moving to types?

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

What do you mean by types being dealt with at the IDE level?

Depending on your type system, a well-typed program can eg run faster, because the compiler / interpreter can elide certain runtime safety checks that would be necessary in untyped code.

If your type system is crazy enough, you can even track the runtime complexity of your program at the type level, including whether your program runs in finite time. See eg Dhall (https://dhall-lang.org/) whose type systems only allows programs running in finite time.

Re: Types will be part of Ruby 3 stdlib source

#29

Post by biql »

cocochanel wrote: post #15

Why is everything moving to types?

Harder to make bugs. Better documentation. Typed code is easier to optimize - just look at Crystal performance. Better IDE/Text editor tools. Simpler deploy / distribution - just copy a binary file. I really wish there will be optional type to prevent nil errors at compile time.

Re: Types will be part of Ruby 3 stdlib source

#30

Post by lloeki »

b123400 wrote: post #23

Interesting. I thought the Ruby community generally prefers shorter code, e.g. `to_s` instead of `to_string`, and yet that type signature is very verbose: `sig {params(x: Integer).returns(String)}`

Integer and String are the actual classes:

    “foo”.class # => String
Post reply on HN