[phoronixrly]

Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language.

Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.

[ashishb]

> Breaking changes in dependencies end up in production only if you don't have tests.

That's true. However, you have now replaced the work of a compiler with testing.

[dyarosla]

Compilers dont test, or rather, they test a very specific and narrow set of things relative to what youd want to test to maintain a working program

[jiehong]

Refactoring from a function returning a string to another returning a string, and all compiles, yet without tests nothing works in production because it’s not the same string.

On top of that, sometimes mocking in tests also hide the string breaking change you don’t yet know about.

On top of my head, I saw this happen with a base64 string padded vs unpadded, or emojis making their way through when they did not before, etc.

So yeah, the compiler tells you which pieces of your jigsaw apparently fit together, but tests show you if you get the right picture on the jigsaw at the end (or on some regions).

[yakshaving_jgt]

Isn't it a shame that we're only allowed to have one or the other.

[lelanthran]

> Breaking changes in dependencies end up in production only if you don't have tests.

Which are opt-in in dynamically typed languages.

You get the same functionality in statically typed languages and it's not opt-in, AND the developer doesn't have to do the work of type-checking (the compiler does it).

[simultsop]

In a utopic scenario, yes, you fix type-checking and you can live happily ever after.

In an interoperable environment, when additional programming languages/teams are in play, which is very frequent nowadays. You have the problem of centralizing types/entities/schemas, reused types, partial types, and union types, and you can keep the story on.

At some point, instead of typing being an invisible tool, it becomes the tool. Then you superset the tool to other languages, because they are in an immutable state. Another language will emerge with dynamic typing in decades then people will take the same spiral and spend more time to reason wages.

[phoronixrly]

I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you.

Will also keep in mind that tests are optional. This is def. a healthy mindset.

[lelanthran]

> I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you.

who said that?

> Will also keep in mind that tests are optional. This is def. a healthy mindset.

Once again, I have to ask - where did you get that from?

[lmm]

A test suite often ends up acting as an ad-hoc, informally specified, buggy, slow implementation of half a static type system yes.

[phoronixrly]

I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.

[lmm]

The same applies to type systems these days - you don't just express basics like nullable or not, you build high level business concerns into your types.