7 ms·

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 o

by Dude2029 7y ago

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.

smt88 7y ago
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.
- k__ 7y ago
  As far as I know BuckleScript isn't a FB project.
  - chucksmash 7y ago
    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-bloomberg-introducing-bucklescript/ https://www.bloomberg.com/company/press/open-source-at-bloom... [2]: https://reasonml.github.io/docs/en/what-and-why https://reasonml.github.io/docs/en/what-and-why
notus 7y ago
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 https://github.com/facebook/flow/issues/4785
- ryanar 7y ago
  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.
  - pknopf 7y ago
    Sounds like it's on life support. Nobody should be using Flow.
    - kevinb7 7y ago
      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.
      - Arnavion 7y ago
        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).
        kevinb7 7y ago
        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/MYGwhgzhAECCB2BLAtmE0DeBfAUKSMAwmAC7QCmAHiefACYwIpqbTLkD2A7gBQCUmLNFz4o0ACIcA5hWq0GcJKnQZoXDhwBm-QcJw5NAV3jASiDvGiaNPMErQQAXIuYgA2gF0BGHNGh3XCAA6AAdDCAALHnhyLglpPhxcPAsIMmBSJ2hiEk9oAF5oNxi4nI8Abn1rDh4Mkgg+SqA https://www.typescriptlang.org/play/#code/MYGwhgzhAECCB2BLAt...
- spoiler 7y ago
  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.
- jey 7y ago
  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-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... 2. https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+is%3Aopen+%24ObjMap https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+i...
tengbretson 7y ago
This mirrors my experience. I really wanted to like their Nuclide editor, but it was a broken out of the box experience every time.
alde 7y ago
Yes, so true. Wish Facebook stated this explicitly on their projects readmes.
bartq 7y ago
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.
coding123 7y ago
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.
tyri_kai_psomi 7y ago
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.
- sdegutis 7y ago
  Microsoft almost definitely has a 30-year-plan with TypeScript that is only slowly being revealed.
- leeter 7y ago
  > 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.
- WorldMaker 7y ago
  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.
ernst_klim 7y ago
> 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.

smt88 7y ago

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.

k__ 7y ago
As far as I know BuckleScript isn't a FB project.
- chucksmash 7y ago
  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-bloomberg-introducing-bucklescript/ https://www.bloomberg.com/company/press/open-source-at-bloom... [2]: https://reasonml.github.io/docs/en/what-and-why https://reasonml.github.io/docs/en/what-and-why

notus 7y ago

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 https://github.com/facebook/flow/issues/4785

ryanar 7y ago
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.
- pknopf 7y ago
  Sounds like it's on life support. Nobody should be using Flow.
  - kevinb7 7y ago
    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.
    - Arnavion 7y ago
      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).
      - kevinb7 7y ago
        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/MYGwhgzhAECCB2BLAtmE0DeBfAUKSMAwmAC7QCmAHiefACYwIpqbTLkD2A7gBQCUmLNFz4o0ACIcA5hWq0GcJKnQZoXDhwBm-QcJw5NAV3jASiDvGiaNPMErQQAXIuYgA2gF0BGHNGh3XCAA6AAdDCAALHnhyLglpPhxcPAsIMmBSJ2hiEk9oAF5oNxi4nI8Abn1rDh4Mkgg+SqA https://www.typescriptlang.org/play/#code/MYGwhgzhAECCB2BLAt...
spoiler 7y ago
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.
jey 7y ago
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-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... 2. https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+is%3Aopen+%24ObjMap https://github.com/facebook/flow/issues?utf8=&q=is%3Aissue+i...

tengbretson 7y ago

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

alde 7y ago

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

bartq 7y ago

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.

coding123 7y ago

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.

tyri_kai_psomi 7y ago

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.

sdegutis 7y ago
Microsoft almost definitely has a 30-year-plan with TypeScript that is only slowly being revealed.
leeter 7y ago
> 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.
WorldMaker 7y ago
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.

ernst_klim 7y ago

> 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.