Duck typing is safe (2020)

Re:Duck typing is safe (2020) by nhumrich on Wednesday June 15, 2022 @12:29AM (#31749121)

Things "break" all the time in production, regardless of type system. The amount of instrumentation you have to have anyways makes this whole conversation almost moot. Even {insert your favorite language here} programmers write bugs. Segfaults can happen regardless of language/typesystem.

I haven't seen a single SRE say, "oh, you use X language, with Y type system? Ok cool, you don't need us then"

[ Parent | on HN ]

Re:Duck typing is safe (2020) by smt88 on Wednesday June 15, 2022 @01:09AM (#31749329)

The best apples-to-apples experiment for the value of type systems is JS vs TS.

When I write TypeScript, I have so few runtime errors that I'm often in disbelief. Sometimes I have zero runtime errors on my first test of an application.

Contrast this with my own writing of JavaScript (same coder, same runtime, etc.) and it's very clear. JS needs many, many unit tests that TS just doesn't.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by ok_dad on Wednesday June 15, 2022 @03:40AM (#31750163)

Yea, I program in Python with a very strict type checking configuration, and I have never gotten a runtime error in production due to type related issues (like attribute errors or key errors), only weird edge case stuff or algorithmic mistakes.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by joshuaavalon on Wednesday June 15, 2022 @02:38AM (#31749820)

Things do break in production does not mean you don't take any measures to reduce the chance of happenings.

Following your logic, why should we test our code before deployment?

Everyone should push to master and deploy to production. Things will break anyway even if we tested our code.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by dirkt on Wednesday June 15, 2022 @01:46AM (#31749516)

The goal of a type system is not to prevent all bugs, or to prevent all bad things happening at runtime.

The goal is to catch as many bugs as possible BEFORE it runs in production. And even if you just catch a single bug, you have already won. In particular if the type system is balanced in such a way so there's not much additional effort involved (e.g. by using type inference).

[ Parent | on HN ]

Re:Duck typing is safe (2020) by pessimizer on Wednesday June 15, 2022 @01:15AM (#31749370)

This sounds like the Law of Averages. All things don't break at the same frequency, and noticing that doesn't mean that you're saying that something else is perfect; other things could just break less often, for different reasons.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by UncleMeat on Wednesday June 15, 2022 @11:01AM (#31753974)

Of course. But fixing a bug in production is 100x more expensive than fixing the same bug during development. Ideally, we minimize the number of things we rely on SREs to manage.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by mbrodersen on Saturday June 18, 2022 @10:22PM (#31795565)

Nope. Not true. I haven’t had a bug in production the last 5+ years. And I am maintaining large scale C++ software with massive refactorings and features added. The key is having solid tests.

[ Parent | on HN ]

Re:Duck typing is safe (2020) by mountainriver on Thursday June 16, 2022 @10:12AM (#31766261)

Really? Types languages are way safer and break less, which is what you want and you want breakage to happen as early as possible in the dev cycle for velocity

[ Parent | on HN ]

Re:Duck typing is safe (2020) by deltaonefour on Wednesday June 15, 2022 @02:32AM (#31749781)

Yes but things can break less with a robust type system. This is categorically true.

For example ELM is a programming language that cannot crash due to it's type system. I mean it can crash off of exceeding system resources or through the FFI, but it cannot crash any other way.

The argument the OP is making is that the difference achieved by a type system is negligible, but I would argue that in some cases this is true, but ELM is a case where it's not.

[ Parent | on HN ]