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

41–50 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#41

Post by bfung »

eru wrote: post #27
symlinkk wrote: post #18

Earlier quoted context omitted.

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.

ML family has "type inference", which means the compiler figured out the type even if not explicitly written into the code. However, the language spec is still statically typed - an int will not turn into a string and vice versa (ex: "1").

Javascript and ruby, the underlying types can change depending on where the code is in execution - a variable holding a 1 can turn into a "1" and back (implicit type conversion - try 3 * "3"). This leads to a whole class of bugs not possible in a statically typed codebase where explicit conversion needs to happen - I have no hard data, but I remember debugging this type of stuff far too often and far too many times when I could've spend my time better elsewhere. (but I actually like ruby a lot!)

Type checking is not the same as being statically vs. dynamically typed!

Re: Types will be part of Ruby 3 stdlib source

#43

Post by geraldbauer »

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)}`

The type signature in (secure) ruby [1] - an alternative ruby (subset) with type (optional) annotation - is `sig Integer => String` or `sig [Integer] => [String]. Since the sig is just ruby you can create an alias for types e.g. I = Integer, S = String and than use sig I=>S, for example. [1]: https://github.com/s6ruby

Re: Types will be part of Ruby 3 stdlib source

#44

Post by fouc »

cocochanel wrote: post #15

Why is everything moving to types?

It does seem like there is a fad around moving to types, mostly because of typescript's current popularity.

Will be interesting to see how ruby handles types vs duck typing etc 10 years from now, when the new best practices have been figured out.

Re: Types will be part of Ruby 3 stdlib source

#45

Post by joelbluminator »

jez wrote: post #37
joelbluminator wrote: post #33

My concern about all of this is that it might lead to basically two ruby communities; Rails and Rails devs will mostly keep writing type free code (dhh has always indicated he's not a fan of types), but a lot of other rubyists will gradually introduce types into their code. This could create two different ecosystems with different gems, best practices, blogs etc etc etc. We will see how it plays out but I'm quite con…

It’s not in the tweet but we specifically covered that it’s possible to type check Rails in our talk actually: - https://sorbet.run/talks/RubyKaigi2019/#/53 - https://sorbet.run/talks/RubyKaigi2019/#/55 So I don’t think that the divide will be at Rails. And more than that, I think there will be very little divide at all. Sorbet is designed to be gradual, so it works 100% fine with untyped code: https://sorbet.org/doc…

Hi thanks for this! Could you shed more light on the last part where they show parts of Rails, Gitlab etc are already typed? How is this possible?

Re: Types will be part of Ruby 3 stdlib source

#46

Post by diminish »

joelbluminator wrote: post #33

My concern about all of this is that it might lead to basically two ruby communities; Rails and Rails devs will mostly keep writing type free code (dhh has always indicated he's not a fan of types), but a lot of other rubyists will gradually introduce types into their code. This could create two different ecosystems with different gems, best practices, blogs etc etc etc. We will see how it plays out but I'm quite con…

typescript, es6, es5....

Re: Types will be part of Ruby 3 stdlib source

#47

Post by baybal2 »

_hardwaregeek wrote: post #6

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in se…

What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?

Re: Types will be part of Ruby 3 stdlib source

#48

Post by coldtea »

baybal2 wrote: post #47
_hardwaregeek wrote: post #6

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in se…

What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?

The rationale is that types are there to check correctness (types as proofs), not to improve performance.

Speed is not the first and foremost benefit of types. Type checking is (and other stuff that comes with that, like better completions, self-documenting code, etc).

Re: Types will be part of Ruby 3 stdlib source

#49

Post by webgoat »

baybal2 wrote: post #47
_hardwaregeek wrote: post #6

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in se…

What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?

Readability most likely. Type checking tends to also reduce basic bugs from mismatched inputs as well.

Re: Types will be part of Ruby 3 stdlib source

#50

Post by trixie_ »

cocochanel wrote: post #15

Why is everything moving to types?

Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you?

If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the job.

It's like a cost/benefit analysis where none of the benefits you're using, and the cost is the total inability to validate, refactor, and navigate your code base.

Post reply on HN