[drujensen]

This reminds me of the studies done related to traffic lights and stop signs.

Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert.

Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax with testing things related to types. When you develop in non-typed languages like Ruby, you tend to write more tests and not trust your compiler (because you don't have one). This is why you will find most Ruby developers are really good at writing tests and embracing TDD.

[moritonal]

You're point is valid, but you really quickly move past just how slowly drivers have to be when there aren't traffic lights. As with everything they're a helpful tool for efficient traffic, just like static compilation.

[kevinmchugh]

I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks.

A type system can keep you from having to write those tests.

[siwatanejo]

> A type system can keep you from having to write those tests.

Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.

[ebingdom]

Those languages don't have null safety, but plenty of languages do. Rust, Kotlin, Swift, Haskell, etc.

The claim is true: a type system _can_ prevent null-related issues and eliminate the need to account for them in tests. That's not the same as saying every type system does.

[campl3r]

Doesn't C# support this by enabling Nullable?

[creakingstairs]

They all have nulls but a static lang will warn you that the value can be null.

[tene]

This is false. There are plenty of languages without pervasive implicit nullability. Check out Haskell and Rust and Ocaml.

[creakingstairs]

You are right. I should have said some. The point I wanted to make was that having type safety is better for checking null than having no type at all.

[shepherdjerred]

It can if you choose to return Optionals instead of nulls.

[ehnto]

That's a good analogy, because just like when an intersection gets enough throughput, relying on drivers to navigate their way through becomes unrealistic. Once a codebase reaches a certain size or complexity, it starts becoming really time consuming to follow untyped logic all over the place and you run the risk of a rockstar developer putting a scooter object into the side door of your minivan object.

Static typing gives you assurances and tools with which to test your assumptions in the code, for those times when reading the whole stack is cumbersome, and you need to defend against less careful developers. It also transfers a bit of knowledge between developers in a trivial way that would otherwise be a pain to communicate.

[p4l4g4]

I think this analog is close to the dynamic vs static debate. However, there are probably more factors to consider, such as competence of the driver (will the driver even care to slow down?), location of the intersection (an intersection just around a shallow corner) and value of the driver's car (does the driver care about a little damage?).

In my experience similar arguments hold for software developers. Especially caring can be a big factor; i.e. the "move fast, break things" mentality.

I've been back and forth between typed and untyped languages (somewhere in the range of haskell and tcl) and personally prefer less typing when hacking things together and more typing for high quality software. I'm currently working an infra job where we use both ansible and terraform. They're not direct competitors, but I tend to prefer terraform over ansible when possible, as terraform gives me more "static" guarantees, which translates to more confidence when we apply our code.