Hacker News Reader

> But the main problem for me is the cost is too high for such little benefit. Understanding and maintaining a type system like that is hard. You are not going to eliminate all bugs. Wouldn't the effort be better spent on writing more tests? I feel like developers prefer creating more types over writing more tests because it's easier, though.

It's not that types are "easier", it's that they give you things that tests either can't provide or don't provide without serious discipline (often lacking in general, but even when present it's easy to let things slip through).

The thing to aim for is both. Since, short of dependently typed languages, it's practically impossible to encode everything into the type system, tests will remain. But types allow you to express things that become tedious in tests and get the same at least as many guarantees as a comprehensively tested code base but without the same dependency on discipline, which doesn't scale.

> This contradicts the Universal part of UUID. If they're not the same then why use UUID at all?

UUID = Universally Unique Identifier. Not "Universal", "Universally". That extra bit is important, it's qualifying the "Unique" part and not the "Identifier" part. But, importantly in the context of the article, UUIDs could refer to different "types" of things (users, inventory items, addresses, transactions, etc.). By adding a shallow (in this case) wrapper around it it prevents trying to do something like receive a User ID (as a UUID) and trying to find it in the inventory database (using the same UUID value).

This is not to remove all sources of bugs, it is a more succinct way to gain guarantees. Typing, as in making types modelling, your domain so that illegal states are impossible to represent implies a lot of tests won't have to be written. Why? Because whole classes of bugs are impossible.

But rest assured, the rest of the bugs are still around so you still need tests. Just not those.

I've worked like this for years now and there's just no turning back.

Do you know how many "null checks" and similar sanity checks are in my code? Close to zero. Do you know why? Do you think I'm a moron or because _those_ things are _actually_ impossible that way.

But rest assured, etc.

It simply cuts down on the amount of certainty that has to be incessantly (re)verified and tested.

Also: when you sit down to model your whole domain in this manner, do you know what you discover? All the things that would be anyway - just further down the line.

"Oh, we don't always have a contract number in these scenarios so _that_ case will have to have a constructor. Oh - that means that this purchase function has to stop "lying" about being able to process any invoice becauase some of them won't have a contract number. Shucks!"

How do you solve that? 4 000 lines of tests and 20 lines of assert hasContractNumber.

> using a List instead of a NonEmptyList when at least one element is expected.

I'm not sure why this is a problem. An empty list is a perfectly valid list. It strikes me that what you really wanted to pass was an object, not a list. ------- Not in every domain. For example - common pattern in FP is to return an Either[NonEmptyList[Error], SomeResult] when parsing. You can clearly see why the list of errors should never be empty

I don't know about Scala, but List vs NonEmptyList is a huge problem in Haskell since head [] -> throws an error. There was an article on HN a week or so ago about how to deal with this in a type system where it ultimately felt like they were reinventing nil punning.