Hacker News new | ask | show | jobs
by mirekrusin 1091 days ago
This can't be solved by static analysis - anything that crosses i/o boundary has to be asserted, refuted or predicated at runtime and you have libraries for it ie. [0] which doesn't throw (based on refutations which can be mapped to predicates without much cost and assertions) or [1] which throws (based on assertions).

Predicates are the most performant but won't give you any indication on why it failed (ie. some nested field was null but was expected to be number etc).

Refutations is great sweet spot as it's fast while giving information about error.

Assertions are slow, but more often than not you don't care.

You can map between any of them, but it doesn't make much sense for mapping ie. assertion to predicate as you'd be paying cost for nested try/catch while dropping error information.

Refutation is great base for all 3.

[0] https://github.com/preludejs/refute

[1] https://github.com/appliedblockchain/assert-combinators

1 comments

The complaint is that Typescript not emitting any of the type information for the runtime means every library must reimplement the whole TS type system.
Yes, that's true, they could support emitting metadata with explicit keyword which would help and wouldn't bloat anything implicitly, they already do emit code for enums for example.

Personally I'm fan of not introducing new language that runs at comp time, just use the same language to have macros and operations on types for free - just like Zig does it.

Typescript type system is already turing complete so it's not like they'd be loosing anything there.