Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

So this basically summarizes as "A) the goal is to reduce runtime errors so manage your time well, also B) linting tools are good at doing that quickly"?

I feel like it could really use a couple examples of situations where type safety is a waste of time. As-is the post vaguely suggests a tradeoff and doesn't elaborate.

View on HN

I think it's not saying that time is wasted but that it could be better spent verifying the same thing with other techniques. For example you could implement a graph type that guarantees absence of cycles at all point. Such a type would be great except for the fact that in most cases you would be better off preventing such cycles by construction, e.g. by only adding edges directed towards nodes that are not added yet.

> It’s only useful because of what it accomplishes: moving errors from runtime to compile time. Even that isn’t a goal on its own. The real goal is reducing runtime errors. Type safety is one of the best methods of achieving these cascading goals, but it’s far from the only one.

Why is an example necessary for this? It's trivially correct.

> It's trivially correct.

That's the problem. You can't develop a meaningful sense of balance if you only say trivially correct things.

And the specific need for an example is situations where you could use type safety but don't want to.

It doesn't take into account the whole range of errors that can creep into runtime. If a type system only moves 2% of programming errors to compile time, but costs you in terms of coupling, complexity, and effort, it may not be worthwhile. This is especially true if you can catch that same two percent of errors with tests instead, and avoid the coupling and effort penalties.

Personal opinion: Type systems are more useful for initial code comprehension and tooling than for writing it in the first place, or preventing bugs.

Reply on news.ycombinator.com