[joelbluminator]

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.

[jez]

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

[joelbluminator]

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?

[z1mm32m4n]

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...

[theredbox]

Can you comment something about the possibility of Ruby getting faster because of Sorbet ? Can it be combined with DragonRuby or other compilers that would produce more optimized Ruby programs?

[kgilpin]

I’m curious which projects you used to try this out on?

[zem]

I really like python's approach, which is to provide syntactic support for type annotations, but have them treated as pure comments by the language runtime. That way, type checkers can check your code if you like, but no one is forced to use typed code if they don't want to, even if they are using a "typed" library.

[black-alert]

Yes it is optional until it gets hard to find a job with typeless Ruby. And indeed split Ruby communities just as with Javascript. The bad thing is that static typing in dynamic languages is HOT, which means if you don't move over to the typed camp you will look old and stupid.

[59nadir]

If anything, dynamically typed languages (without special tooling) is for super smart people or people who are lying to themselves/others about the limitations of the human mind.

But I personally wouldn't hire someone who maintained that dynamic typing produced as good results and was reasonable for an even mid-sized project. They've either never had a long running project or they've never dealt with a big enough code base at that point, or they're simply being dishonest or lack self awareness. None of those are good signals. Not having worked on a project that goes on for long enough is fine, but having opinions on software maintenance in that case is foolish.

[DyslexicAtheist]

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

[diminish]

typescript, es6, es5....