I can't downvote you but I want to point out that the only thing you accomplish with such a comment is coming off as ignorant and bitter.

I have no idea why on Earth you think the type system is broken. Objectively, it simply isn't, obviously, but I'd love to see you trip over your own feet trying to argue that it is.

Moreover, it's honestly remarkable how they've managed to retrofit such an amazing type system on top of an already existing language and have it feel so natural. It's truly an impressive feat of engineering.

I don't know if 3.5 fixes this, but here's an example from 3.4

    function messUpTheArray(arr: Array<string | number>): void {
      arr.push(3);
    }

    const strings: Array<string> = ['foo', 'bar'];
    messUpTheArray(strings);

    const s: string = strings[2];
    console.log(s.toLowerCase())

You obviously can't push a number into an Array<String>, yet typescript allows it.

For my money, ReasonML is a better solution for type issues (hindley-milner types are awesome).

Interesting, though it does flag the push() as an error if you use "Array<string> | Array<number>" as the argument type.

It almost seems like some sort of co/contravariance issue?

A function that reads from an Array<string | number> should be able to accept either an Array<string> or an Array<number> (or Array<string | number>), but a function that mutates it should only be able to accept Array<string | number>?

It seems like both projects have their own raisons d'être along with trade-offs.

TS is pretty well-integrated with JS ecosystem and supported by a large player, but has an imperfect type system; Reason is more “puristic” with pattern matching and all, but you have to keep your eyes peeled for impedance mismatch.

(The docs for Reason, or BuckleScript to be exact, have warnings like “If you come from JavaScript, a Reason object doesn't compile to a JS object” sprinkled here and there.)

I personally encountered the case you described a couple of times but generally using TS still saved me a lot of time I’d have wasted debugging, with minimal time spent on getting into the ecosystem.

> Objectively, it simply isn't, obviously

To be fair, TS has some pretty bad unsoundness problems, especially regarding co/contra variance in generics, and for example some annoying weirdness with number/string keys in objects. Still, the type system is one of the most amazing ones I know.

Yeah but if you think about it they are putting a straight jacket on a madman while a committee organizes regular PCP shipments to said madman.

That they got it to work amazes me, that they got it to work well astounds me.

It's one of the few parts of my stack that I interact with every day I don't occasionally want to hunt down the creators of.

> It's one of the few parts of my stack that I interact with every day I don't occasionally want to hunt down the creators of.

Reactive Extensions was definitely one of those pieces of stacks.

Could you help me specify why TS is a broken type system ? Thanks you very much.

They may have been talking about how TypeScript's type system is (intentionally) unsound. For example see https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-fun... and the notes on soundness in https://www.typescriptlang.org/docs/handbook/type-compatibil....

No kidding. I thought you were being facetious but reading the changelog it's clear that most of these would typically have been in a high-priority 3.4.1 release as a number of them are blocking (now there's code that compiled under 3.4 with nary a warning that won't compile under 3.5).

Right. Just read the changelog. It's literally regression fixes on compilation performance (which is introduced by typescript to begin with), and providing work arounds to do things typeless when new syntax feature XYZ is launched.

I'm getting a lot of flack on this thread but I stand by my judgement that working with typescript is slower and more frustrating for frontend work than standard JS.

My experience is just and anecdote, but I'd make a considered choice to pick typescript over minimal JS frontends. A large portion or this is based on my previous experience, so that is what it is.