[pmarreck]

looks like they're adding an optional type system, which means you get the worst of both worlds- no guarantees AND no compile-time type checking (think: what happens if type-checked code calls non-typed code?) so I have no idea how they're going to make that fast since all types will still have to be checked at runtime

[sosodev]

Are you sure it’ll be awful? Sorbet (https://sorbet.org/) is pretty popular already. It can statically check your whole project and dynamically check it at runtime. It also doesn’t add that much overhead so I’m not sure what you’re on about...

[pmarreck]

What does it do with your library code that isn't type-specified? If it infers types, isn't there a limit as to how far that can go?

[dbalatero]

Not sure what Ruby core will do, but Sorbet will type everything as T.untyped in the absence of type hints. Libraries can progressively provide rbi files to add first class type support though.

[oomkiller]

Sorbet looks really cool, too bad they developed their own typing system that keeps types in a totally separate file instead of adopting it.

[jamesgeck0]

Sorbet was developed before the details of the new Ruby type system were locked in. They’re working on providing some convergence in upcoming releases.

[tomc1985]

The 'separate' file is to avoid breaking backwards compatibility and avoiding a Python2/3 fiasco

[virtue3]

Also see coffeescript, etc.

[Lio]

Sorbet will be compatible with the new file format. We’ll still be able to use the inline Sorbet type signatures.

My personal hope is that typing can be included in test/spec files.

[cjohnson318]

I use type hints in Python to make my code more readable and more clearly convey my intent, although I rarely use analysis tools.

[jnwatson]

It works great for Python.