RBS, Ruby’s new type signature language

> How about checking that a given string is non-blank?

Because when you try to do this with some object that doesn't have a "length" or "empty?" method, your application crashes.

    irb(main):013:0> a = 1
        => 1
    irb(main):014:0> b = "1"
        => "1"
    irb(main):015:0> b.length
        => 1
    irb(main):016:0> a.length
        Traceback (most recent call last):
            4: from /usr/bin/irb:23:in `<main>'
            3: from /usr/bin/irb:23:in `load'
            2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
            1: from (irb):16
        NoMethodError (undefined method `length' for 1:Integer)
    irb(main):017:0> b.empty?
        => false
    irb(main):018:0> a.empty?
        Traceback (most recent call last):
            4: from /usr/bin/irb:23:in `<main>'
            3: from /usr/bin/irb:23:in `load'
            2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
            1: from (irb):18
        NoMethodError (undefined method `empty?' for 1:Integer)

This is why people want a way to know if something they think is a String is actually a String, without risking data loss and outages at runtime.

I think it's rude to dismiss people asking for this as "fixated," and furthermore it could be no less fairly used against people who show up to these debates beating their own drum against it.

One can check that something is a string and not a blank one.

There are two different libraries that do it:

https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73...

https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a...

Honestly I highly suspect that many, many "typing" solutions out there are plain ignorant of the whole spectrum of choices one can make, are tend to lean towards Java-like APIs out of that ignorance.

This is not limited to Ruby, I also see it in TypeScript which is very much a contrived system for real-world usages while making little use of JS's dynamism.

I'm glad we agree that adding type annotations to code is a good thing. You aren't arguing against that–you are just arguing implementation details. If I'm designing a 5 9s service tasked with processing gigabytes of data every unit time, I don't want to pay the runtime cost of checking the types for every mundane operation like measuring the length of a string.

Design by contract (which the mentioned libraries excel at) isn't a new thing, and the mentioned one is a solved problem. https://en.wikipedia.org/wiki/Design_by_contract#Performance...

It is evidently not a solved problem. Why would large financial services companies be working on these things we're talking about if that were the case?

Do you know what solves the problem of checking every type of every thing you want to use before you use it, where the checks don't incur any performance penalty at runtime? Static type checkers!

Modern compilers usually don't even require any explicit type declarations, as they can infer at assignment. So they provide more safety for less code than your examples.