Types in imba vs. types in ruby


Knowing a little about the history of imba, I know it is very heavily inspired by ruby.
However, I notice that the relationship between types and objects in imba is quite different than that of ruby. In ruby, everything is an object. This means that any data in ruby is going to share some common behavior, for example:


all return either true or false, we can send the nil? message to anything without concern for what the thing is-- there is no concern of returning an error. In imba, if I want to gaurd against a null input I need to write:

return if subject == null

which is bulkier and less human-readable than

return subject.nil?

The example I provide is not fantastic, but there are many methods defined on the ruby object that are amazingly useful and contribute significantly to the brevity/readability of ruby code and result in much more significant gains to the readability/brevity of the code (such as Object.then). I’m wondering what the reasoning is for not replicating this pattern in imba. Possible reasoning’s I could come up with were:

  • It was too difficult to produce performant/readable JavaScript?
  • We want to keep the imba types as similar to JavaScript as possible?
  • It was too much work for the payoff?
  • It conflicts with the vision/philosophy of imba? (we don’t want this kind of syntax in imba even if it was just as easy to implement and as performant)

I am just trying to get a good understanding of what imba is trying to accomplish (beyond the goals stated on imba.io), what is motivating it’s design, so that I can manage my expectations for it!

1 Like