Every technology created at Facebook is meant for internal use. The wider community then goes through the pain of making it usable. Microsoft's mission on the other hand is pleasing developers hence VS Code and TS.

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.

I've never used Reason, but I find OCaml very easy to set up. This probably depends a lot on how well-supported your editor is. My setup involves:

    sudo apt-get install opam inotify-tools m4
    opam init
    opam switch 4.07.0
    opam install dune merlin ocp-indent

and then add the ocaml layer to my spacemacs config. This gives me auto-indenting, syntax highlighting, type hinting, and my preferred build tool (dune w/ inotify).

FWIW, this was much worse when I did it a couple of years ago. I think the ecosystem has made pretty big strides recently, much of which came from standardizing on dune as the canonical build system.

I have to admit, Reason is a bit more obscure.

I installed bs-platform and still got errors from my IDE about bs-platform missing.

Which was strange, since I used the bs-platform CLI tools.

Turns out you also had to have bs-platform installed locally, but the error messages didn't say anything about this, just "bs-platform not found".

This shouldn't happen, did you make sure to yarn install and restart the reason language server?

Maybe that was my problem, many project setup tools do the install automatically, you just need to cd and npm start.

I typically install all what you listed, and tuareg. Worth noting that after installing these packages, they tell you how to configure your text editor, or you can choose to let them handle it for you automatically (IIRC). So yes, it is pretty easy to set OCaml up.

I believe the spacemacs ocaml layer pulls in tuareg automatically, but that's a good point for other setups.

You are looking for "reason-language-server". You can download a VSCode extension with it from the VSCode "marketplace", and if you use a different editor like Vim you can use the language server with whatever vim language server plugin you prefer.

I will admit this is a little bit more confusing than would be ideal, because there is also an older ecosystem called "Merlin". If you are a reasonml beginner, avoid plugins that use Merlin.

I spent hours following the (multiple sets of disparate) instructions to set RLS up, and I was never able to get it working so I gave up on ReasonML. I like the concept, but it needs to be as easy to get up and running as Rust/Rust's "RLS".

What is the issue with merlin? Are you referring to https://github.com/ocaml/merlin? I have been using it (with OCaml) without any problems.

Merlin requires opam, which is yet another tool beginners need to fight with. Reason support for Merlin was relatively recently merged, so it might work ok right now- but I couldn't get it to work with Reason the last time I tried. I agree it works fine with Ocaml.

Unfortunately I could never get RLS to work for me. I opened an issue on it, but it seems like the small group of people with the same issue haven't had the time/drive/knowledge to fix it. The maintainer doesn't want to fix it himself, but I don't blame him, he doesn't have the same error :/

Maybe it will be ironed out someday...

Care to share the issue? I'm willing to look into this

There was a workshop at the last ReasonLDN meetup. Here are the slides that were used, they include quickstart instructions: https://docs.google.com/presentation/d/1wuAveSHslRfKShD6SiVd...

If I recall correctly, everyone managed to set things up swiftly, with an exception of one Windows user who had some editor issues.

> how _poor_ the experience was setting up an editor with autocomplete and type hints.

What? Merlin does all of these right out of the box, and supports emacs, vim and LSP [1]. The setup is basically `opam install merlin` and then `your-editor-package-manager install ocaml/reason-mode`

[1] https://github.com/ocaml/merlin

Nowadays I'd be surprised at people having trouble setting up ReasonML tooling. It should be just:

- npm install --global bs-platform # (you need to ensure you have write access to the global install path)

- Fire up VSCode

- Install the reason-vscode extension

- Run `bsb -init my-project -theme react-hooks` (assuming you want to scaffold a new ReasonReact project)

More details at https://reasonml.github.io/docs/en/editor-plugins

I agree with you. Reason was harder to set up, but it got better nowadays.