Hacker News Reader

> it's not sound

This comes up in every one of these threads and I always wonder: do you actually experience problems with soundness in your regular coding? (Aside from `as unknown`, which as others have noted just means you need a linter to stop the bad practices.)

It feels like such a theoretical issue to me, and I've yet to see anyone cite an example of where it came up in production code. The complaint comes off as being more a general sense of ickiness than a practical concern.

yes, all the time. It's more of an issue of no runtime type safety, which makes it a poor choice for many backend projects. There are workarounds, but it's silly when there are many better alternatives.

> It's more of an issue of no runtime type safety...

This is a completely orthogonal question to soundness.

In this case, not really. TypeScript can't be sound because there is zero runtime type safety in JS. That you are able to do `as unknown as T` makes TypeScript unsound, but it's also an escape hatch often needed to interact with JavaScript's dynamic typing.

> an escape hatch often needed

The only time you need that is in tests.

Otherwise you're better off using guards then blindly casting

The code base I work on has more test code than production code.

> often needed

It's never needed, it's just often convenient for something quick and dirty. You can always write a guard to accomplish the same thing—roll your own runtime safety. If you want to avoid doing it manually there's Zod. It's not that much different than writing a binding for a C library in another language in that you're manually enforcing the constraints of your app at the boundaries.

Soundness is a constraint more than a feature. Having it limits what is possible in the language, forcing you into a smaller set of available solutions.

So for me it's not about running into unsound types regularly but how much complexity is possible and needs to be carved away to get at a working idea because of it. In TS I spend relatively a lot of time thinking about and tweaking minute mechanics of the types as I code. Where by comparison in ocaml (or more relevantly rescript) I just declare some straightforward type constructors up front and everything else is inferred as I go. When I get the logic complete I can go back and formalize the signatures.

Because of the unsoundness (I think? I'm not a type systems expert) TS's inference isn't as good, and you lose this practical distinction between type and logic. And more subtly and subjectively, you lose the temporal distinction. Nothing comes first: you have to work it all out at once, solving the type problems as you construct the logic, holding both models as you work through the details.

You're blaming TypeScript for self-inflicted wounds.

Don't blame the type system that you banished (with `as unknown as T`) for not catching you; or for some React library having bugs, e.g. an incorrect interface; for not defining types and Pikachu-facing when types are `undefined`. These traumas are fixed by using TypeScript, not ignoring it.

These issues don't exist in languages that aren't built on a marsh.

More specifically though, I feel like the way javascript libraries with types work is often painful to use and that's why people use TS's escape hatches, whereas the same thing doesn't happen in languages where everything is built on types from the get go.

The same friction is true for example of using C libraries from other languages.

"don't exist in languages that aren't built on a marsh"

Sure. Last time I checked, JavaScript is the language that actually powers the web. If you can get a language that isn't built on a marsh along with all the libraries to run the web, I'll switch in a second.

In other words, the criticism is simply irrelevant. If it works, it works. We don't talk about technologies that don't exist.

We do in fact talk about technologies that don't exist. Creating new technologies would be rather difficult otherwise.

When they don't have to interface with JS apis (e.g., for the DOM) this is true for libraries in other languages built for WASM.

Not run on the web, "to run the web". Maybe someday WASM will be complete enough to actually run the web, but JavaScript is what we have right now and it's done a pretty okay job so far.

> These issues don't exist in languages that aren't built on a marsh.

Unsafe casts exist in almost any GCed strongly typed language. You can unsafe things even in Rust, if you want to. Author of this code has deliberately made a choice to circumvent language's limitation and forgo it's guarantees. We have been doing it since undefined behaviour in C, how is that Typescript's fault?

> Unsafe casts exist in almost any GCed strongly typed language.

Well, and not GCed languages too. There are even weakly typed associative arrays.

  std::map<std::string, std::any>

The rest of the world is an equally muddy marsh. C++: static_cast, C: void-pointers and unions, java/c#: casting back from (object) or IAbstractWidget.

If anything, typescript has the most expressive, accurate and powerful type system of the lot, letting you be a lot more precise in your generics and then get the exact type back in your callback, rather than some abstract IWidget that needs to be cast back to the more concrete class. The structural typing also makes it much easier to be lax and let the type engine deduce correctness, rather than manually casting things around.

C is famously unsafe. But in Java/C#, you do have runtime type safety. You can't just cast something to something else and call it a day. In the worst case, you'll get an exception telling you that this does not work. In TypeScript, the "cast" succeeds, but then 200 lines later, you get some weird runtime error like "does not exist on type undefined" which doesn't tell you at all what the source of the error is.

In TypeScript, a variable can have a different runtime type from its declared type entirely, that's just not true for many other languages

I'm not sure about the CLR, but the JVM has no type safety whatsoever. Java the language does, but all of that goes away once you are in the JVM bytecode.

> the JVM has no type safety whatsoever.

This is just partially true (or completely untrue in the mathematical sense since your statement is "_no_ type safety _whatsoever_" :P ). The whole purpose of the bytecode verifier is to ensure that the bytecode accesses objects according to their known type and this is enforced at classloading time. I think you meant type erasure which is related - generic types do not exist on the bytecode level, their type parameters are treated as Object. This does not violate the bytecode verifier's static guarantees of memory safety (since those Objects will be cast and the cast will be verified at runtime), but indeed, it is not a 100% mapping of the Java types - nevertheless, it is still a mapping and it is typed, just on a reduced subset.

Well, the reality of the situation still is that there are libraries with incorrect or low quality typings that blow up in your face. Me using TypeScript will not make that library better, but this problem is still the daily reality of using TypeScript. It's not the fault of TS, but still a pain you encounter when working with it.

I haven't worked with a language where you can statically cast invalid types that easily since C, a language not exactly famously known for its safety.

There's a reason `as unknown as T` exists, and it's JavaScript's highly dynamic nature and absence of runtime types (ignoring classes and primitives). It's an escape hatch that is needed sometimes. Sure, within your own codebase everything will be fine if you forbid its use, but every library call is an API boundary that you potentially have to check types for. That's just not great DX

I haven't worked with a language where you can statically cast invalid types that easily since C, a language not exactly famously known for its safety.

But it’s not the same situation at all, is it? If you make an invalid cast in C, your program will crash or behave in bizarre ways.

If you make an invalid cast in TS, that doesn’t affect the JS code at all. The results will be consistent and perfectly well-defined. (It probably won’t do what you wanted, of course, but you can’t have everything.)

TS is much more like Java than it is like C (but with a much nicer type system than either).

Meh, in Java (afaik) you'll get exceptions when you cast incorrectly. In JS and C, it just gets allowed and you get some runtime error later on and have to make your way back to find your incorrect cast.

Totally! I really wonder what these libraries people are complaining about that have such bad type definitions. In my experience TS definitions on the average NPM package are generally fairly decent.

I tend to agree with you but for problem like this one:

> That you can just do `as unknown as T` is an endless source of pain

You should be using strict typingcheck/linting rules somewhere in your pipeline to make these illegal (or at least carefully scrutinised and documented).

Those rules should be enabled by default.

ESLint rules that require type information (not just stripping types) are prohibitively expensive for larger code bases.

As far as I know, there isn't any kind of tsconfig rule to disallow this (please correct me if I'm missing something here!). So unless you're using tools I don't know about, this is kind of a mandatory last bastion of "any".

You can disallow any, enable the strictest possible null/undefined checks (including noUncheckedIndexedAccess). And there's also the assertion TS check that normally prevents erroneous type assertions.

But "as unknown as MyType" is not preventable by means of tsc, as far as I know. Unless there's an option I don't know do disable this kind of assertion (or even all assertions).

How large is too large and what counts as prohibitive? We're using lints with types on over a million lines of TypeScript and the lints are instant inside of the editors. They take a good 10 minutes to run in CI across the whole project, but that's shorter than the tests which are running in parallel.

I think it depends on your code and dependencies. At work, the time between making a change in our codebase (which is much smaller than a million LOC) to having ESLint update itself in the IDE can take 5+ seconds, depending on what you changed. But we also use some pretty over-engineered, generic-heavy dependencies across our entire codebase.

Good point, I was talking about similarly sized code bases, yes.

Because of the hefty CI runtime increase, myself I opposed to adding it. We have lots of parallel branches that people work on and many code reviews every day, where the CI just needs to run from a clean slate so to speak.

But most of the current long CI run penalty in the frontend of that comes from tsc, not ESLint, in my case.

I might look into it again.

In the project there already are all kinds of optimizations (caching to speed up full Ci runs with common isolated parts of a monorepo).

And for TS, project references + incremental builds for development are used, tsc in a monorepo would be miserable without them.

lint-staged on pre-commit and full lint in CI solves this problem very well.

Sure, I agree in general, but I've found that:

1. If someone is willing to do `as unknown as T`, they're probably also just as willing to do `// @ts-ignore`. 2. It's not only your own code, it's the libraries you use as well. Typings can often be slightly incorrect and you have to work around that occasionally.

For #1, this is literally what PRs are for. Someone might be willing to do it, but it should be stopped before merge. If it isn’t, you have bigger problems to solve than type coercion.

For #2, if it’s open source you’re welcome to change the source or its typings.

Popular libraries tend to get type hygiene issues ironed out rather quickly for 90% of the API surface area. For this reason, i find that lib selection from npm is much easier these days. The heuristic is simple:

1) has types? 2) has (large) download count? 3) has docs?

After that it’s generally smooth sailing. Of course this doesnt at all apply to the application codebase being applied to, but one of the parent/sibling remarks emphasized “madness” and i seek to smooth that over.

Noisy? Yes. Madness? Nah.

Don't you care about whether it's an abandoned project, how many dependencies it has or its license?

Your simple heuristics seems like a bad approach to me.

You can also turn off all warnings in C and C++ (and C#?). That's not a flaw in the language it's a flaw in code bases and programmers that turn them off.

Then fail builds on @ts-ignore.

"But the bad dev will just open up your build config and remove that restriction."

Okay fine. At some point you gotta establish a floor on the insolence of your teammates.

> Having no integer types (ok, this isn't something typescript could just implement) other than BigInt is another big one for me.

Is that a performance thing? I believe JavaScript VMs can specialize/optimize Numbers and BigInts that only contain valid 32 int values.

None of these are performance concerns. Modern JS engines are plenty fast for most of my use cases.

It irks me that I can't trust it to be an integer within a given range. Especially with Number, I often have the sensation that the type system just doesn't have my back. Sure, I can be careful and make sure it's always an integer, I've got 53 bits of integer precision which is plenty. But I've shot myself in the foot too many times, and I hust don't trust it to be an integer even if I know it is.

As for BigInt, I default to it by now and I've not found my performance noticeably worse. But it irks me that I can get a number that's out of range of an actual int32 or int64, especially when doing databases. Will I get tto that point? Probably not, but it's a potential error waiting to be overlooked that could be so easily solved if JS had int32/int64 data types.

Do you have any more specific examples where it has caused a problem not having int type specifically?

I can't really remember having a problem with it myself, but maybe your usecases are different.

Not really. In my parent comment I tried to make clear that it's not a limitation for me in real-world scenarios I encounter, but still something I feel like being a potential class of problems that could be so easily solved.

When I really needed dedicated integer types of a specific size, e.g. for encoding/decoding some binary data, so far I've been successful using something like Uint8Array

Sound currency arithmetic is a lot harder when you have to constantly watch out for the accidental introduction of a fractional part that the type system can't warn you about, and that can never be safe with IEEE 754 floats. (This doesn't just bite in and near finance: go use floating-point math to compute sales tax, you'll find out soon enough what I mean.)

Bigints solve that problem, but can't be natively represented by JSON, so there tends to be a lot of resistance to their use.

I’m converting a billing system from js to ts right now.

Looking for a therapist.

> Especially with Number, I often have the sensation that the type system just doesn't have my back.

That's sounding dangerously close to dependent types, which are awesome but barely exist in any programming languages, let alone mainstream general purpose programming languages.

You could do this with a branded type. The downside will be ergonomics, since you can't safely use e.g. the normal arithmetic operators on these restricted integer types.

> As for BigInt, I default to it by now and I've not found my performance noticeably worse. But it irks me that I can get a number that's out of range of an actual int32 or int64, especially when doing databases. Will I get tto that point? Probably not, but it's a potential error waiting to be overlooked that could be so easily solved if JS had int32/int64 data types.

If your numbers can get out of the range of 32 or 64 bits then representing them as int32 or int64 will not solve your problems, it will just give you other problems instead ;)

If you want integers in JS/TS I think using bigint is a great option. The performance cost is completely negligible, the literal syntax is concise, and plenty of other languages (Python, etc.) have gotten away with using arbitrary precision bignums for their integers without any trouble. One could even do `type Int = bigint` to make it clear in code that the "big" part is not why the type is used.

> That you can just do `as unknown as T`

I mean, yeah... if you're using escape hatches all the time I can see why you are having a bad time.