On Type Safety

I have never understood people’s objection to types in programming languages. In my eyes, the more structure the better. Types are one of the few ways that we can, without running the code, be more confident that our code is correct — that it will do what we mean it to do.

Types provide information to the reader. When I call a function, I don’t have to rely on the variable name, nor examine what the code does to know what to pass. I can see int, string, bool, etc. and know what needs to go where.

In Python, where types are suggestions, the benefit is still obvious.

def my_function(a, b, c):
    # A bunch of code...
    return x

res = my_function(a, b, c)

In the untyped version, I do not have any insight into a, b, c, or the return type. If I accidentally mis-order the variables, I have no way of knowing without running the code.

def my_function(a: str, b: int, c: list) -> bool:
    # A bunch of code...
    return x

res = my_function(a, b, c)

Terrible parameter, value, and function names but I am much less likely to make a mistake on the latter. Add in docstring comments, IDE support, or linters, and the probability of an error drops precipitously.

In a type safe language, the probability drops from low to impossible.

func myFunction(a string, b int, c []int) bool {
    // A bunch of code...
    return x
}

ok = myFunction(a, b, c)

I am unable to pass values with the incorrect type and much less likely for an error to occur in this function from bad data.

This becomes exponentially more valuable as functions call methods, handlers get longer, etc. because one wrong type cascades up the chain. Enforcing quality naming is near impossible — types are linguistic requirements.

Types let code speak for itself.