4 ms·
Regarding TypeScript: > but types lie at runtime (unsound) requiring you to add your own runtime checks. I don't recall doing that outside of situations when
by Tade0 6mo ago
Regarding TypeScript:
> but types lie at runtime (unsound) requiring you to add your own runtime checks.
I don't recall doing that outside of situations when data is crossing system boundaries.
The vast majority of languages have an unsound type system, yet people are productive in them.
Over the years I've come to realise it's a form of nitpicking. You absolutely need it in some applications, but it's not an important requirement most of the time and it's given undue importance by some.
- teaearlgraycold 6mo agoThe main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should return either unknown or a recursive union that defines all valid JSON structures. I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language. When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.
- sargunv 6mo agoEven with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside
- teaearlgraycold 6mo agoVery interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?
- sargunv 6mo agoI'm not aware of a name, but I'm also curious if there is one because I had a hard time searching for it. I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0 https://youtu.be/u1WmiqlrqL0
- teaearlgraycold 6mo agoI asked an LLM and it described the problem as "covariant typing of mutable collections" or "unsound covariance". I'm not mathematically educated in this area but that sounds right?
- saghm 6mo agoYes, that's correct. If you're curious for a slightly more concrete source, Wikipedia covers this reasonably well (although citing one often decried source to validate another might not be particularly convincing to some people): https://en.wikipedia.org/wiki/Type_variance#Arrays https://en.wikipedia.org/wiki/Type_variance#Arrays
- sally_glance 6mo agoI think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.
- fainpul 6mo agoIf it's an "array of strings AND numbers", then it should not be allowed to call the function with a string[], because those are different types.
- clownstrikelol 6mo agoThat’s barely scratching the surface. In TypeScript the following is also valid: class Something{ value: Number } class SomethingElse{ value: Number foo: String bar: SomeOtherThing[] } function AddSomething(v: Something) { v.value += 1; } var ex = new SomethingElse{ value: 3, foo: “TypeScript is fake types”, bar: [] }; AddSomething(ex); Why does it work? Because in TypeScript as long as you have a “shape” that fits, it’s the “same type.” Complete and utter insanity to me, to pretend there’s any real type checking, when types are entirely fake and made up.
- deleted 6mo ago[deleted]
- drzaiusx11 6mo agoYikes. I've only been using ts for about a year, I had no idea this was considered a "valid" case. Seems like a type error to me. I wonder how they justify this?
- stratos123 6mo agoWoah, that's quite an issue. The equivalent code in Python doesn't typecheck, since `list` is invariant and hence list[str] doesn't fit list[str|int]. Unusual for TS to handle types worse than Python.
- Tade0 6mo ago> You don’t want to throw too many red squigglies at early adopters and cause them to give up. That's not the reason. TypeScript's main design goal was to enable developers to gradually introduce types in codebases that spent years being written purely in JS. There's still demand for this feature and those who start off with TypeScript set their own config anyway. I've dealt with people using all kinds of escape hatches, but 2/3 of the time it's caused by lack of proficiency in the language. The rest is either someone being in a hurry or just not serious about their job.
- satvikpendem 6mo agoWith TypeScript 6.0 and above it is indeed much stricter by default.
- jim33442 6mo agoI agree. Ironically have inherited a lot of projects where they picked a "type-safe" language but didn't properly type the system boundaries, including RPC and database. Wrong priorities there.
- tracker1 6mo agoAdjacent to the article... there are a lot of bits from WCF I really liked and miss. I didn't really like a lot of the default way to use it... I generally would combine all the interfaces and a client instance generator into a single library to share (as opposed to the XML config crap the people tended to default with). Today, there's tooling around OpenAPI/Swagger, but I don't think it's nearly as nice as using WCF for the server and client interfaces directly.