[the_duke]

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]

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.

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.

[tlrobinson]

It sounds like you want “deno compile” (https://deno.land/manual@v1.25.4/tools/compiler) plus “no-explicit-any” eslint rule (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]

That 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]

You want C# with dotnet AOT.

[zoom6628]

You beat me to it. Exactly this - use C#.

[cjonas]

Last I checked C# didn't have an algebraic type system...

[Smaug123]

But F# is sitting in the corner with an eyebrow cocked suggestively.

[TDiblik]

C# 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.

[lioeters]

I suppose AssemblyScript fits some of those points: no any or unknown; compiles to a binary; GC; cross-platform.

[zozbot234]

> 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?

[zarzavat]

There’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]

About 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>>.

[math_dandy]

How about F#?

[staticassertion]

I 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.

[Tade0]

> 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.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]

Yeah, that's pretty different. That's still the programmer having to think about types as a separate entity or a runtime construct.

[alpaca128]

Another 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]

> 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.

[mhermher]

I 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.