Strict type-system for Ruby?

I just read once-more Julien Blanchard’s blog post about a type system for Ruby. As we all know, Ruby uses duck-typing. That means that Ruby doesn’t care what type an objects says it is, it cares about what the object can do. It’s one of the things that makes the language so flexible, it allows us to write code like that:

def my_length(obj)

knowing that this code will work for any object that supports the #length method, regardless of its ‘type’. It means we don’t have to overload this method again and again to deal with different argument types, as we would do in a statically-typed language. it’s a beautiful thing, one of the very things that makes Ruby, well…Ruby.

I am surprised to see that there is a movement of people within the Ruby community who want to have a static type-system, including overloading, casting and other associated nasties. I developed code in C++ for over 12 years before I started learning Ruby. I spent a significant part of those 12 years fighting the language’s type-system, telling it things like

“hey, this object over there is a std::string but I want you to convert it to a char*, because that’s how someone declared it in a function signature, although they are essentially the same thing and it shouldn’t really matter because I only want to use its bloody length anyway”

I really, really don’t want to go back to this. I know, from experience with both, that static typing’s drawbacks far outweigh the benefits. I appreciate there are use-cases for static typing but, you know, for such use-cases go use Java, Scala or whatever other language floats your boat. Let’s keep Ruby truly dynamic.

To paraphrase Ben Franklin: “Those who are prepared to sacrifice permanent flexibility for temporary safety deserve neither!”


I believe I either read or saw a conference talk on the upcoming Ruby 3 and that they’re doing “Soft-Typing”. Apparently there are many different things involved with typing and Matz has 3 focusses for it. Matz at RubyConf 2014: Will Ruby 3.0 Be Statically Typed?

The impression I got from it is it wasn’t going to be “Strict” as much as it would be optional. Right now types are determined at runtime (instantly) and/or inferred. Having the option of Typing would enhance debuggers and performance time.

There is currently a gem available to write your own typing in a comment before methods and variables. I don’t remember what that gem is, but here is a similar one: contracts.ruby

Tom Stuart does a good job covering this in this conference talk: Consider static typing


I believe many people don’t understand what duck typing is. (I believe you have it right.) If you are doing if statements and the :is_a? method then you’re doing it wrong.

I believe the Null Object Pattern is a perfect example of DuckTyping. You create a Null type of the object that will be used and then the receiver method/Object won’t check for the type… it just does its thing. If you give it the wrong Type of Object then it will fail. I believe this is the proper intent of DuckTyping. Duck quacks and NullDuck quacks.

And as I understand it DuckTyping is a Pattern.

For the record I’m not an expert and am majoritively self taught. So feel free to correct me.


I don’t know how I feel about this atm tbh - on the one hand performance gains need to be made, on the other, I like Ruby it the way it is.

Ultimately, I will lean towards whatever helps Ruby and its future…

1 Like

I appreciate that it would, but I’m worried about what it will do to the language’s expressiveness and fluidity. Also, there’s no such thing as ‘optional’ typing. If one module / gem / piece of code you’re relying on uses typing then you need to use it too. The option is not yours to take.

Yes, that’s the one Julian is referring to in his blog

Too right, that’s one of the ways I can tell if some code has been written by someone who’s recently moved to Ruby from Java or C# (the other is by looking for if obj != false kind of statements LOL!)

Yes indeed, the NOP is a good application of duck-typing though it can be overkill sometimes.


I am a user of contract.ruby.
The reason of NOT using respond_to? is that naming is difficult and could cause false positive result.
I like the fact that it is optional by default (as long as Contract is not called) and quite flexible.
I hope Ruby will have similar “feature” and have “some” performance boost compared to existing gems.