Hacker News Reader

Comment by nhumrich | Hacker News Reader

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"

View on HN

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.

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.

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.

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).

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.

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.

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.

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

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.

Reply on news.ycombinator.com