Hacker News Reader

Comment by storafrid | Hacker News Reader

I have mixed feelings about this. While I do use TS with Node.js today and absolutely like the concept, its type system is still far from something mature and stable like C#. We keep running into ceilings (EDIT: lack of completeness/depth, not lack of complexity) all the time, and TypeScript questions on Stack Overflow is basically a library of workarounds. Mostly bad ones. So if I worked on Node.js I would prefer it to evolve more before actually marrying and having kids with it. But at the same time, I like the direction Node.js is taking.

View on HN

What's an example of a ceiling? Out of all the mass-market programming languages, TS arguably has the most advanced type system in the world. It's a modern marvel that they got it working on top of Javascript.

I don’t know what you mean here by advanced? If you mean the sheer amount of fuckery they have to do in order to make it work with JS perhaps you have a point.

If you mean expressiveness or consistent or soundness then no, it’s actually very bad compared to almost anything else and I think the longer it goes on the more it starts to feel like a house of cards.

The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options.

There is no way I’d choose JavaScript over those other options in the majority of scenarios unless I was forced to.

> The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options.

Out of those three only Dart has nice DX story compared to JS world.

I think it took the seemingly impossible challenge of bringing typing to a dynamic language that made typescript so powerful in the first place.

All other static languages start bottom up, simple to more complex, but end up getting boxed in by their own design. TypeScript started top down, trying to map itself on to a fully dynamic language. Never getting boxed in, just trying to 'fill' the box that is all the possibilities of JavaScript. 10 years on and TypeScript is still exciting, making significant updates and improvements.

Typescript isn't particularly powerful compared to other non-mainstream languages, though, which is why the parent comment was careful to add that caveat. Which is to say that I'm not sure the idea that "all other static languages" start simple and get boxed in stands up.

You may have a point that Typescript would have been relegated to obscurity with all the others had it tried to start "top down" as a brand new language. There may be some truth that it is a necessity of a language to start simple in order to become accepted in the mainstream and that Typescript only made it because it rode on the coattails of a language that also started simple: Javascript.

Certainly advanced, but not mature in my experience. Using e.g. classes and inferred generic function arguments, quickly reveals a lot of features that are missing. Often some similar feature is present but it lacks depth/completeness. Lots of good discussions to read in TS repo on GitHub if you're interested: Optional generic type inference, extends oneof, generic values, keyof a subset, conditional types, etc.

I want to emphasize that the reason we keep running into "ceilings" is probably because of its advanced type system. Libraries and frameworks are using those type features and when we can't keep building on the type - we end up casting to unknown and reconstructing it. Which feels worse than not being able to construct that complex type at all.

This is the first time I'm hearing such a claim.

In C# you can't work with optional generics because an optional reference type is different from an optional value type.

C#s poor type-inference often requires you to type out types thrice. You can't declare constants or class members with type-inferrence.

The only way to define sum-types (A | B | C) is through intefaces and I'm pretty sure they can't be sealed. Defining product-types (A & B & C) is impossible.

Sorry I probably used the wrong term, not a native English speaker. I didn't mean lack of complexity or lack of "features" but rather the lack of carefully thought-through feature "depth". Like, we can infer generic arguments which is nice, but then we try doing that with some keyof complex type and it doesn't work. And later we find an issue on GitHub saying that it's not implemented. Which is fine, I love TS anyway and it's evolving.

C# has record (product) types now.

I'm not sure about the terminology here, but the & in TS is much more than a record. You can use it to smush types together e.g.

{name: string} & {birthday: Date}

becomes a single type with both properties.

Product types are tuple types.

Record types are tuple types with names instead of indexes.

The TypeScript “&” is another thing.

Well said. Bearing that in mind, we've found that JSDoc is a reasonable substitution for some TypeScript applications; however, JSDoc has limitations that we've ran into frequently as well.

Reply on news.ycombinator.com