Live data from Hacker News

Use Your Type System

dzombak.com

321–330 of 357 posts

Re: Use Your Type System

#321

Earlier quoted context omitted.

> I think Rich Hickey has a point that bugs like this almost certain get caught by running the program. That is certainly correct... but that doesn't make it a good thing. One wants to catch bugs before the program is running, not after.

Depends which is quicker. If I catch a trivial bug on the first run, I just saved myself writing the type system to find it ahead of time.

When a bug like this can cause real world harm, we can't just bumper car program our way out of things. As engineers we should be able to provide real guarantees.

Re: Use Your Type System

#322
post #25

Earlier quoted context omitted.

Yep. For this reason, I wish more languages supported bound integers. Eg, rather than saying x: u32, I want to be able to use the type system to constrain x to the range of [0, 10). This would allow for some nice properties. It would also enable a bunch of small optimisations in our languages that we can't have today. Eg, I could make an integer that must fall within my array bounds. Then I don't need to do bounds ch…

Ada has this ability to define ranges for subtypes. I wish language designers would look at Ada more often.

And I wish people would remember Pascal and Modula-2 had it before Ada. :)

Re: Use Your Type System

#323
post #103

Earlier quoted context omitted.

If only Java also provided Either -like in the standard library... Personally I use checked exceptions whenever I can't use Either and avoid unchecked like a plague. Yeah, it's pretty sad Java language designer just completely deserted exception handling. I don't think there's any kind of improvement related to exceptions between Java 8 and 24.

Ok please help me understand, what is the difference between - R method() throws L, and - Either method() To me they seem completely isomorphic?

I would say one we are allowed to bash upon, forgetting the history of key programming languages with checked exceptions predating Java (CLU, Modula-3 and C++), whereas the other is the cool FP programming concept that everyone coding is coffee shops is supposed to find cool.

Semantically from CS point of view in language semantics and type system modelling, they are equivalent in puporse, as you are very well asking about.

Re: Use Your Type System

#324

Earlier quoted context omitted.

> So Java's checked exceptions force you to write verbose and pointless code in all the wrong places (the "in the middle" code that can't handle and doesn't care about the exception). It doesn't, you can just declare that the function throws these as well, you don't have to handle it directly.

It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method. This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.

You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?

Re: Use Your Type System

#325
post #224
post #37

An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…

C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue. I also think its a bit cleaner to have a nicely pattern matched handler blocks than bespoke handling at every level. That said, if unwrapped error results have a robust layout then its probably pretty equivalent.

Until routinely prod goes down with that exception that no one cared to handle, been there done that.

Re: Use Your Type System

#326
post #324

Earlier quoted context omitted.

It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method. This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.

You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?

Yes, the exact same problem is present in languages where "errors are just values".

To solve this, Rust does allow you to just Box (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.

Re: Use Your Type System

#327
post #324

Earlier quoted context omitted.

You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?

Yes, the exact same problem is present in languages where "errors are just values". To solve this, Rust does allow you to just Box (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.

Go as usual, got this clever idea to use strings and having people parse error messages.

It took until version 1.13 to have something better, and even now too many people still do errors.New("....."), because so is Go world.

Re: Use Your Type System

#328
I'm using typed IDs in TypeScript with template literal types. I.e. `type UserId = `user_${string}` I've written a blog post about it a while ago [1] One can argue that this pollutes runtime, however, it is a feature to me. When the ID pops up in the logs, it is instantly obvious what the object is, error messages are more meaningful. You can notice that Stripe uses such approach in their API.

[1] https://www.velopen.com/blog/adding-type-safety-to-object-id...

Re: Use Your Type System

#329
post #325
post #224

Earlier quoted context omitted.

C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue. I also think its a bit cleaner to have a nicely pattern matched handler blocks than bespoke handling at every level. That said, if unwrapped error results have a robust layout then its probably pretty equivalent.

Until routinely prod goes down with that exception that no one cared to handle, been there done that.

For something like a web request, all the frameworks catch the exception at the request level. Prod should not be going down.

Maybe you mean requests are failing on uncaught exceptions, in which case I'd say it's working well.

Re: Use Your Type System

#330
post #329
post #325

Earlier quoted context omitted.

Until routinely prod goes down with that exception that no one cared to handle, been there done that.

For something like a web request, all the frameworks catch the exception at the request level. Prod should not be going down. Maybe you mean requests are failing on uncaught exceptions, in which case I'd say it's working well.

For the customer there is hardly any difference that the server keeps running if a critical workflow, especially with a payment in flight, crashes and burns.

Or if they are unable to work, because they keep getting a maintenance page, as the load balancer redirects them after several HTTP 500 responses.

Post reply on HN