4 ms·
Typescript has a decent type system, but it is really held back by being "just" a type checker for JS, with all the JS semantics. The way sum types are done in
by the_duke 4y ago
Typescript has a decent type system, but it is really held back by being "just" a type checker for JS, with all the JS semantics.
The way sum types are done in TS is really awkward.
The type system is unsound.
What's worse is that you never have a guarantee that the types are actually correct at runtime, due to bad third party typings, compiler limitations, use of any, ...
It's still a lot better than using plain JS, and a lot of the limitations aren't by choice, but come from the need to compile down to and remain compatible with plain JS.
It just could be so much better.
- enlyth 4y agoI wish Microsoft would make a language almost exactly like Typescript, but where code has to be strictly typed (no any, unknown, etc.) and it would compile to a normal binary, with some sort of GC, for multiple platforms. It would hit the sweet spot for me, I know Rust is popular these days, but it seems like it's made for type astronauts, and sometimes I just want to write some code and get things done quickly and don't care about squeezing out every last drop of bare metal performance or abstracting seven layers of types to please a borrow checker.
- lioeters 4y agoI suppose AssemblyScript fits some of those points: no any or unknown; compiles to a binary; GC; cross-platform.
- math_dandy 4y agoHow about F#?
- tlrobinson 4y agoIt sounds like you want “deno compile” (https://deno.land/manual@v1.25.4/tools/compiler https://deno.land/manual@v1.25.4/tools/compiler) plus “no-explicit-any” eslint rule (https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-explicit-any.md https://github.com/typescript-eslint/typescript-eslint/blob/...). Or are you wanting a language with different semantics that could be compiled to actual machine code?
- yencabulator 4y agoThat still allows `x as string` and many other traps. Typescript just isn't type-safe, and this has bitten me so many times in real world projects with strict mode and all. The best thing I can say about Typescript is that it's an improvement over Javascript.
- d3nj4l 4y agoYou want C# with dotnet AOT.
- zoom6628 4y agoYou beat me to it. Exactly this - use C#.
- cjonas 4y agoLast I checked C# didn't have an algebraic type system...
- Smaug123 4y agoBut F# is sitting in the corner with an eyebrow cocked suggestively.
- TDiblik 4y agoC# does not have "type" keyword and really lacks behind with enums. You can theoretically replace algebraic type system with inheritance, however that's a lot of times ugly and you propablly shouldn't do it.
- zarzavat 4y agoThere’s no such thing as “fully sound” type system, outside theorem provers like Lean. Every type system has a trapdoor. Rust has “unsafe”. Haskell has “unsafePerformIO”. And TypeScript has “any”. Soundness is just as much a property of a language’s culture as its implementation. Practically I find that TypeScript is sound enough for my purposes when most of the strictness options are enabled.
- graftak 4y agoAbout 90% of any can and should be replaced with unknown which is infinitely more useful and a lot safer. There is an example signature at the end of the article; (x: any) => string, this error would not fly if x were unknown. On of the few remaining scenarios where any might be necessary is to narrow down a generic param, ie <T extends Something<any>>.
- zozbot234 4y ago> I wish Microsoft would make a language almost exactly like Typescript, but where code has to be strictly typed (no any, unknown, etc.) and it would compile to a normal binary, with some sort of GC, for multiple platforms. Isn't that what ReasonML is for?
- Tade0 4y ago> The type system is unsound. I've never seen this as a barrier to producing working software. Meanwhile Dart is sound, bit but doesn't have nearly the same adoption.
- staticassertion 4y agoI agree with your point that TS is held back by being "just" a type checker. In particular, in Rust I can write code like this: let _: Result<Vec<_>, _> = some_iter.collect(); or like this: let _: Vec<Result<_, _>> = some_iter.collect(); The only thing that has changed here is the type annotation. Both will compile, but the implementation of `collect` is determined by that type. As far as I know this isn't the case in typescript, although please tell me if I'm wrong, I have limited experience from it and I'm thinking more from mypy perspective. This ends up meaning that my types don't drive the program as much. There's this sort of declarative "here's the thing I want, use an implementation of that method to give it to me" that feels very powerful. I miss this a lot with mypy, my type annotations feel very much like annotations, they are a separate part of my program. If TS were to lean into itself as its own thing, not just a way to do better JS, I think that'd be amazing. I'd love to see an AOT compiled TS where types are a semantic part of the program, I'd love to see it drop `any` entirely as well, and drop support for using JS in TS. As for soundness, don't care too much tbh.
- alpaca128 4y agoAnother annoying part of this is how every function declaration effectively doubles the list of parameters, once as type signature and once in the usual JS function syntax. And those don't even have to match, neither in length nor name of the parameters.
- Tade0 4y ago> please tell me if I'm wrong There's no exact equivalent, but you can use generic functions or function overloads to achieve something similar: https://www.typescriptlang.org/docs/handbook/2/functions.html#generic-functions https://www.typescriptlang.org/docs/handbook/2/functions.htm... Of course it won't select an implementation for you, so you'll have to handle all the possible type combinations yourself in the function body.
- staticassertion 4y agoYeah, that's pretty different. That's still the programmer having to think about types as a separate entity or a runtime construct.
- mhermher 4y agoI think a lot of those decisions were made to maximize easing existing JS code into typescript. And it probably helped with adoption. Who knows if or how much it would have struggled with traction if anyone wanting to use it would have to start from scratch or something like it.