Live data from Hacker News

Types will be part of Ruby 3 stdlib source

twitter.com

31–40 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#31
post #10

It's an interesting turn of event that Ruby, Python and JavaScript are all getting types. Meanwhile, I've gotten myself more and more into Clojure. Which now that other dynamic languages seems to move closer to types, seems to be in a niche in that Clojure is moving further away from types. It'll be interesting to see what happens at both extremes and in the happy middles.

Why not a standard Common Lisp istead? Or even Scheme/Racket?

Re: Types will be part of Ruby 3 stdlib source

#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 conflicted about this one. The good thing is that it's optional.

Re: Types will be part of Ruby 3 stdlib source

#35

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…

perl6 and python3 were my first thought. I think this is great though, but maybe they should change the naming of this new version completely so that they can make a clean cut. Rather have less backward compatibility and clean design as opposed to forcing a square peg in a round hole

Re: Types will be part of Ruby 3 stdlib source

#36

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.

In an ideal world, humans write bug-free code ;)

But honestly, if you're asking your IDE to do it, that means you're asking your IDE to do static analysis of your code - and type-checking in a lot of ways is just another static analysis technique. And for a lot of us (myself included) we prefer to catch as many of these bugs as possible using static analysis, instead of waiting for someone to get paged when it causes an outage.

Yes, there's a trade-off, and types can be obnoxious (Java imports being probably one of the worst offenders, C++11 introduced `auto` for a reason), but that's the cost we pay.

Re: Types will be part of Ruby 3 stdlib source

#37

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/docs/gradual

Re: Types will be part of Ruby 3 stdlib source

#38

Earlier quoted context omitted.

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?

It rarely happens to me that I stare at a variable and have to wonder what type it is. And yes, an IDE like Rubymine is becoming crazy good at autocomplete and method lookup. I think the experience of developing on Rubymine isn't that far behind from Intellij nowadays. Not everyone have to use the same IDE, the vim or emacs guys will have to find equivalent tools.

Re: Types will be part of Ruby 3 stdlib source

#39

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.

Ruby being so dynamic means that without type annotations you cannot infer the type (or types) within a variable statically, so you basically have to eval the program, which in Ruby means basically running the whole codebase.

So, please, be brave and evaluate a 100kloc codebase+deps that may contain a top level `rm -rf ~/`

Re: Types will be part of Ruby 3 stdlib source

#40

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.

By IDE level, you mean compile level. Types are at compile level.
Post reply on HN