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

51–60 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#51

Post by z1mm32m4n »

joelbluminator wrote: post #45
jez wrote: post #37

Earlier quoted context omitted.

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?

Sorbet has multiple Strictness Levels[1]. The two most relevant ones are `typed: false` and `typed: true`. `typed: false` is the default level and at this level only errors related to constants are reported, like this one:

https://sorbet.run/talks/RubyKaigi2019/#/14

But we'd like to catch more than just errors related to constants, like those related to missing methods, or calling a method with the wrong arguments. Errors like these are only reported in files marked `typed: true`:

https://sorbet.run/talks/RubyKaigi2019/#/19

Sorbet doesn't need to have method signatures to know whether a method exists at all, or what arity that method has.

But more than that, Sorbet ships with type definitions for the standard library. So you don't even need to start annotating your methods to type check the body of your methods, because most of the body of your methods are calling standard library things (arrays, hashes, map, each, etc.).

The statistics in those slides are sharing "out of the box, what's the highest strictness level that could be added to a file without introducing errors?" So ideally an entire project be made `typed: true`, but Sorbet can be adopted gradually, so a project can exist in a partial state of typedness. We wanted to see how painful it would be to adopt Sorbet in a handful of large, open source rails projects, and it turned out to be not that bad.

[1]: https://sorbet.org/docs/static#file-level-granularity-strict...

Re: Types will be part of Ruby 3 stdlib source

#52

Post by coldtea »

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.

Well, classes are types in a language where everything is an object. It's the same in Smalltalk, no?

Re: Types will be part of Ruby 3 stdlib source

#53

Post by nurettin »

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?

so that you can gradually add types?

now that ruby has an actual jit compiler, it could benefit from typing to optimize code further. And a gradual migration process will help people speed up parts of their code. Unless they mess it up like python where abstractions are costly.

Re: Types will be part of Ruby 3 stdlib source

#54

Post by aasasd »

phaedryx wrote: post #8

I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI This might be misleading. That is, jump to around the 29 minute mark where he talks about the type profiler and .rbi file stuff.

As a user of Homebrew, I just wonder if Ruby's ever going to have performance.

Re: Types will be part of Ruby 3 stdlib source

#55

Post by z1mm32m4n »

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?

Who's to say we couldn't use the types to make the runtime faster in the future?

One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code.

If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actually be run. If the signatures lie, then any runtime optimization made using the types would only be overhead, because the runtime would have to abort the optimization and fall back to just running the interpreter.

[1]: https://sorbet.org/docs/runtime

Re: Types will be part of Ruby 3 stdlib source

#58

Post by black-alert »

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.

I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that.

Now the JS fanboys discovered and moved (from Coffeescript to Babel ESxx) to Typescript they apparently think that they can write beautiful and bugfree software just because of static type checking! Let them please move to C++ or whatever statically typed language and shoot themselves in the foot by making all those mistakes that have nothing to do with static type checking at all! Oh, and of course hitting the wall because they are missing their precious 'any' keyword!

I totally agree that type checking for dynamic languages should be done in the IDE, tooling. But static typing in the dynamic language world is a hype at the moment, so we'll have to go through a wave static type checking frenzy. For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint..

Re: Types will be part of Ruby 3 stdlib source

#59

Post by arnvald »

auvi wrote: post #2

when Ruby 3.0 will be released? 2022 Christmas?

Not necessarily. There are certain things the core team wants to add to Ruby 3.0 and once all goals are reached, the next release will be called 3.0 (so we might possibly see Ruby 2.8, 2.9, 2.10 etc before).

The earliest possible date (and somewhere I read it's a probable one, but I can't find it right now) is Christmas 2020.

Post reply on HN