Ugh yeah, the same thing happened with Flow. Massive immediate adoption by react developers and then FB basically saying "screw you" no roadmap and we're never going to add the features you want. I think I still have an open issue in the flow repo for a roadmap.

EDIT: haha here it is https://github.com/facebook/flow/issues/4785

Flow engineers communicated a few months back to the community saying that they do care, they just were a small team working on the project and had pressing issues at FB to solve first. They mentioned that Flow was really slow for the large-scale projects that existed at FB and so performance was the immediate concern and that ate a year of time after they open sourced the project.

Sounds like it's on life support.

Nobody should be using Flow.

This really depends on what you care about. Flow is much better at ensuring type safety in your code while TypeScript has some pretty glaring holes in this respect. In particular, TypeScript allows covariant assignment and param passing which makes it really easy to write unsafe code.

The covariant param passing was fixed some time ago with the (now on-by-default) `strictFunctionTypes` option. Eg `function f(cb: (_: Animal) => void) { cb(new Dog()); }` can no longer be used as `function takes_cat(_: Cat) { } f(takes_cat);`

Assignment is still there though (ie you can still assign a `Cat[]` to an `Animal[]` and push a `new Dog()` into it).

I believe that `strictFunctionTypes` only applies to callbacks. TypeScript is okay with the following code even with that option turned on:

  class Animal {}
  class Cat extends Animal { meow() {} }
  class Dog extends Animal { woof() {} }

  function foo(animals: Animal[]) {
    animals.push(new Dog)
  }

  const cats: Cat[] = [new Cat];

  foo(cats);

https://www.typescriptlang.org/play/#code/MYGwhgzhAECCB2BLAt...

Your example is identical to the case I covered in the second paragraph of my comment. ie your code compiles because it is legal to assign a `Cat[]` to an `Animal[]`, as I said.

When you mentioned "covariant param passing" I assumed you were referring to the long-lasting issue about callbacks, hence my original comment mentioning that that issue has been fixed. It's not useful to differentiate between "assigning a value to a variable of a certain type" and "passing a value to a function parameter of a certain type" because those are identical.

I'd bet Flow is basically being replaced by ReasonML at Facebook[1]. Bolting a sound typesystem onto Javascript is really hard, and Flow is making a truly valiant effort, but it seems to have stalled out. Instead, ReasonML is based on starting from a "cleaned up" semantics and type system, then translating it into raw Javascript. This avoids all the weird edge cases and type inference problems one runs into when trying to use Flow[2].

(I don't ever have to have any `any` in my ReasonML code, but it was unavoidable with Flow.)

1. https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

2. https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+i...

The way the team communicates with the community is sometimes frustrating. Also, a lot of the decision-making (especially around React/JSX typing) happens behind closed doors, with little to no explanation as to why they were made.

I'd argue Yarn, React, Jest, PyTorch, Hack (and flow even if it's not used much) are examples that show not true. GraphQL may be one of the one of the only examples that needed a bit more to be usable outside of Facebook. All of the others are generally usable out of the box.

I remember when people got excited about Hack, Flow, and Nuclide (or whatever the Facebook IDE was supposed called), but eventually realized the same things that you and GP realized.

Microsoft has paying customers who are devs, and FB doesn't. That explains a lot.

As far as I know BuckleScript isn't a FB project.

It isn't[1]. It's a "partner project" to ReasonML which ReasonML relies on[2].

[1]: https://www.bloomberg.com/company/press/open-source-at-bloom...

[2]: https://reasonml.github.io/docs/en/what-and-why

Yeah, FB releases libraries only to avoid walled garden situation when they can't hire new people because they're not pre trained or they don't want to use closed and internal only technologies. Remember React licensing problems? These days most of frontend jobs are actually React jobs, which i don't like, I like vanilla web.

Over the time I began more and more appreciate Microsoft's "boringness" (which is debatable itself) because their tools are real products, not marketing tools for developers. What matters more for serious project is tools quality, not few hot CS ideas loosely implemented on a knee.

Rust was created to solve's Mozilla's problems with C++

Go was created to solve Google's problems with C++ and engineering at scale

The fact that TypeScript wasn't created to solve a big issue internally at Microsoft is exactly what makes me skeptical of it and personally I view it as a trojan horse, just like VSCode. Sure, today it is done for benevolent reasons, maybe, but what about tomorrow? What if that trillion dollar market cap starts tanking? Then The benevolent VSCode and TypeScript ecosystems become levers to pull in the great big machine.

I would almost feel better if I knew it's stated explicit purpose upfront and what Microsoft's long term goals to monetize the ecosystem/platform were, because then I know what I am signing up for.

Typescript was created to solve big issues internally at Microsoft, to deal with JS at scale. Microsoft has huge JS codebases, almost all of which are Typescript today. Office.com (including in-browser, online versions of Word, Excel, PowerPoint), Outlook.com, OneDrive.com, portal.azure.com, dev.azure.com, and so on. Microsoft may not be as recognizably a "web applications" company, but they do have a number of really big web applications, and they had real scaling problems with JS that Typescript was directly built to help with.

VSCode was started to see if they could build a good web application for development. Portions of it directly power a number of tools of Azure (on portal.azure.com), portions of it also directly powered the Dev Tools inside IE10+ and Edge "Classic". Bundling the web app into an Electron container after it had already paid for its own engineering efforts several times over as reusable sets of components for multiple large web apps Microsoft needed hardly seems like a "trojan horse" to me.

> The fact that TypeScript wasn't created to solve a big issue internally at Microsoft

AFAIK it was, the issue was the poor quality of Javascript development they were having and their inability to really get good tooling and static analysis. Then it kind of exploded as other people said "That's cool" and they then pushed it out as open source so that if they did need to let it go it wouldn't be totally dead in the water.

You speak with authority, but with ignorance. MS had a lot of JavaScript and needed to put some semblance to the madness of development. Read early history. Watch some talks of Hejlsberg, they are insightful and makes you a better developer.

TypeScript was created to solve issues with front end development at MS, its just that they were also genuinely interested about solving other people's problems.

Microsoft almost definitely has a 30-year-plan with TypeScript that is only slowly being revealed.

> Every technology created at Facebook is meant for internal use.

Technology is a stretched term for ReasonML. It's a simple syntactic sugar for OCaml. It uses standard OCaml compiler and standard JS transpilers, like js_of_ocaml and bucketscript.

This mirrors my experience. I really wanted to like their Nuclide editor, but it was a broken out of the box experience every time.

Yes, so true. Wish Facebook stated this explicitly on their projects readmes.