[pixelrevision]

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right.

However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value type” greatly reduces the amount of paths you have to go down when you have to change something or understand what’s going wrong with it. Tradeoff is you end up with a lot more code to maintain...

[quonn]

It helps a lot with refactoring and many other things even early in the project.

For example I‘m using TypeScript with a GraphQL code generator. Now let‘s assume I add a new value to a GraphQL enum. I run codegen, then fix everything until the compiler is happy. Afterwards, all places where this enum was ever touched will take it into account correctly, including mappings, translations, all switch statements, conditions, lists where some of the other values are mentioned and so on.

This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really.

I rely on this daily.

[archarios]

You could do the same process if you used dynamic typing and good test coverage. Just make your change and keep fixing tests until everything is green.

[wtetzner]

But how could you have written tests against that new enum value if it didn't exist before? You would need to know in advance which places needed to be tested for it.

[Ar-Curunir]

Then you essentially are implementing a type checker in your tests, but worse

[pavel_lishin]

I would change that "5 years" to "5 months" (or maybe even 5 weeks), and argue that you can just as easily be that "someone else" on a long enough time-scale (and I don't mean 5 years.)

[dahauns]

That hits closer to home than I'd like to admit. :)