Hacker News Reader

Comment by keithwhor | Hacker News Reader

My claim is only type-safety at the HTTP layer. This claim is intentionally specific! As per another comment in this thread, pedantry is the most valuable currency on HN, so this sort of feedback is not only expected but welcome.

View on HN

It's not pedantry, you're using the term wrong. I understand why it can be confusing if you are just using JavaScript and you haven't had the experience of type-safe codebases. Type-safe does not refer to runtime anything, it refers to the developer being able to refactor their interfaces safely, meaning that the type system informs you of any errors across the entire codebase and all of the dependants of that software. Type safety really means "developing with type safety". Type validation on the other hand, can mean runtime type validation, which is what this software is doing, runtime type validation at the HTTP layer, which is a cool project I admit, very useful stuff, but the term type-safe here is misleading.

Type safety originates from academia, where it refers to the fact that unexpected (ill-typed) operations are prevented. It does not necessarily require any sort of static checking, even though the two are often associated.

Type safety means that no operation receives "unexpected" inputs, but the definition of "unexpected" is not fixed in stone and can vary depending on the context, which makes it a fuzzy concept. If I only define + on integers, and allow `"a"+"b"`, then that's unexpected and must be prevented somehow to be type safe. If I define + on integers or strings, it is fine.

Here using "type safe" is warranted, because the system prevents you from making HTTP calls with unexpected arguments - even though the validation occurs at runtime and the result may be an exception.

(Edit: well to be strictly fair it's not really type-safe because nothing prevents the HTTP endpoint's expected arguments to change under your feet)

I have to stretch my imagination a lot to see how "type-safe" can mean "it throws at runtime".

The term "type safety" was coined in a context where "does random things then ultimately segfaults (if you are lucky)" is a possible alternative.

Fair enough; if I were to change the qualifiers associated with the project, what’s cool about what exists here and how would you describe it in a way that’s maximally appealing? Is “type-safe” an acceptable generalization given an audience less sophisticated than you or can I use a different framing to the same effect?

For this software to be appealing it would need to really be type-safe, meaning you'd need to use TypeScript. Type-safe means I can change an interface in project B and project A that depends on B now shows me errors in the editor exactly where I need to visit to fix it. If that isn't happening, it can't be called type-safe or generalized to that term. Currently it's a type-unsafe HTTP endpoint runtime type validator.

That’s good feedback! We can probably do both; if you think it’s cool would you be interested in contributing to TypeScript support to circle the square?

For sure! Do you pay money $$$? :)

Feel free to email keith@instant.dev if you’re legitimately interested :)

Reply on news.ycombinator.com