This is what I have seen typically as the primary value. Seems less valuable in the age of AI. Also, requires nearly 100% adoption of typing throughout the code base to have the full graph. I still find runtime typing a stronger value proposition, especially for a dynamic language like Ruby

Genuine question: what is the essential benefit of static type checking? I understand the core benefit of runtime type checking—to guarantee that certain states, inputs, outputs are never allowed to flow thru the program. But I’ve never quite grokked what makes static type checking valuable

Nick, you need to check out www.youtube.com/watch?v=G9rx... which is a demo of what we are building with github.com/yippee-fun/e...

Deep magics. But built on top of `require-hooks` gem.

And we continue writing that love letter with the new Empirical gem, which leverages the power of pre-processing Ruby at boot time to bring a terse and elegant DX for defining methods with runtime typing constraints.

github.com/yippee-fun/...

Once you then embrace that you can create your own objects that respond to === and encode custom rules of “set inclusion”, you have everything you need to a rich and robust runtime type system. The Literal gem is @joel.drapper.me and I’s love letter to ===

github.com/yippee-fun/...

Massive props to Vladimir and team for such an awesome tool. “Compile-time” macros for Ruby open up such a wild range of possibilities!

This tool is the foundation of Joel and I’s recent work on Empirical (github.com/yippee-fun/...) which enhances Ruby with strict instance variable reads, typed method signatures, and a rich runtime type system.

I don’t know if I’ve come across that gem or not, but it is quite similar to many we have seen, like github.com/joelmoss/del.... We just fundamentally don’t love that DX of method decorators 🤷

Types are best seen as a tool for making your system more clear and correct. Improved DX is a nice by-product, but it isn’t primary.

Assert what you know must be true. Maybe you don’t think of all assertions at first, maybe you add an assertion that you later realized shouldn’t be there or should be different. That is fine. Software evolves as our understanding of the domain and system evolves. But better to know w/ clear traces.

joel.drapper.me/p/omission-...

This is why I advocate for runtime assertions. It’s impossible to test every possible scenario ahead of time, but you can test every actual scenario just in time.

The former is always preferable to the latter. Bugs of omission are easier to detect and fix. The consequences are bounded and predictable. In contrast, bugs of commission are difficult to detect and the consequences can be devastating, unlimited, sometimes irreparable.