Hacker News Reader

Comment by tacotacotaco | Hacker News Reader

Typescript won because is doesn’t ask developers to write better code, only that they write more code. As you pointed out, its syntax is familiar enough to be non-threatening to existing devs and its type system is completely optional in so far that I’ve worked with clients whose devs proudly proclaim their project is typescript yet they have _no_ types defined. Not that the type system is good anyway and I’m not even talking about `any`. That’s why it is so frustrating to me. Yes, we need a strong typed language but typescript’s type system is just disappointing, so of course it’s popular.

Typescript does make the devs _feel_ like it’s secure and that’s more important. Marketing works.

View on HN

Why is it disappointing? TypeScript's type system, via pseudo-dependent-types, is much more powerful than Elm's, Rust's, Haskell's etc. The only problem is that it's not sound, but JS itself is not sound, so TS can never be.

> JS itself is not sound, so TS can never be.

What?

The type system is not sound… that is there are things which the type checker cannot prove.

Not that the languages themselves are unsound.

1. That's a horrible description of unsoundness; you're making it sound like incompleteness!

2. What I meant to ask was: what does satvikpendem mean by "JS is unsound"? It's a dynamically typed language, so they can't be talking about soundness in the type system...

I did a bit of a writeup on the gaps in soundness for TypeScript in the docs, https://www.typescriptlang.org/play?strictFunctionTypes=fals...

I should clarify, the JS type system is unsound, and because JS is valid TS, TS is by extension also unsound. Not sure why you'd think a dynamically typed language cannot be unsound, it still has types, they're just not static.

Define soundness. Here's something close to the definitions that I've seen:

> The central result we wish to have for a given type-system is called soundness. It says this. Suppose we are given an expression (or program) e. We type-check it and conclude that its type is t. When we run e, let us say we obtain the value v. Then v will also have type t. - https://papl.cs.brown.edu/2014/safety-soundness.html

This only makes sense in the context of static types afaict, because you do not "typecheck an expression" in a dynamically typed language.

Types can be checked at runtime too, not just compile time. A language is sound if all types, even at runtime, are what they say they are. Zod for TypeScript is one example of checking this at runtime, although it's not fully safe either.

Soundness is not decidability. The reason TS is unsound is not directly because it's undecidable, as any Turing complete system is undecidable, and the TS type system is Turing complete.

Typescript exists so you can press ‘.’ and find out what the npm library you just imported can do.

Types are more important/useful for library code than business/presentation logic. Typescript lets you can hire devs who can’t read documentation or understand type systems write javascript to stitch together enough imports to make something work.

Even if you aren't using types in first-party code, you're getting autocomplete and inline docs for all the third-party code, including the standard DOM API's, or NodeJS, or whatever types from your NPM modules. There's value in having that even if you live in a mostly `any`-typed codebase (which is likely more common than anyone's letting on).

Reply on news.ycombinator.com