Hacker News Reader

Comment by django77 | Hacker News Reader

I agree that this can be nice when done right (Clojure), but null is a high price to pay for this convenience.

I must admit I’ve never had this problem in application development. In fact, I do want to change my callers because strengthening the contract is an opportunity to simplify the callsites - they no longer have to handle the optionality. The change might carry some semantic meaning too, why are you getting x instead of Maybe x all of the sudden? Are there some other things you should reconsider in the callers? I can see how it could be useful in library development, but there are also patterns to account for this that are idiomatic to Haskell.

View on HN

> I agree that this can be nice when done right (Clojure),

I don't think Clojure has untagged union types like TypeScript or Scala.

> but null is a high price to pay for this convenience.

Why would it be? Untagged unions prevent null pointer errors just as much as option types do, only they don't have the discussed disadvantages of option types.

> Why would it be?

That's literally what they explain in the rest of the comment.

No, they don't reference any "high price to pay", only that they personally didn't need the advantages of untagged union types so far, and that Haskell (allegedly) has patterns that would play a similar role for libraries.

I was thinking about a general experience of working with null/nil. Clojure has nil punning which makes sense in the context of the language (lisp variant) and can be nice to work with.

The null is a high price to pay because eventually someone will make some type assertion somewhere in the TS codebase that will end up biting you. Sure, you can be diligent, but will every contributor during the lifetime of a project be?

Not sure about Scala, but I did see NullPointerException every so often, and what is the practical advice to handle them in Scala? It’s to use Option[T]

> The null is a high price to pay because eventually someone will make some type assertion somewhere in the TS codebase that will end up biting you. Sure, you can be diligent, but will every contributor during the lifetime of a project be?

Type assertions and untagged union types are entirely independent. Supporting untagged unions doesn't imply supporting type assertions, and not supporting untagged unions doesn't imply not supporting type assertions.

> Not sure about Scala, but I did see NullPointerException every so often, and what is the practical advice to handle them in Scala? It’s to use Option[T]

Scala only supports untagged unions since version 3, so that's probably the reason why they are not used everywhere yet.

Reply on news.ycombinator.com