Facebook Launches Flow, Static Type Checker for JavaScript

Post by pgroves » Tue, Nov 18, 2014, 10:01 PM UTC

nbm wrote: post #101

pgroves wrote: post #94

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get 'funded'?

That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the…

Post by aliakhtar » Tue, Nov 18, 2014, 10:02 PM UTC

Post by nbm » Tue, Nov 18, 2014, 10:10 PM UTC

logicalmind wrote: post #107

nbm wrote: post #101

Earlier quoted context omitted.

That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the…

I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help…

Post by cwills » Tue, Nov 18, 2014, 10:12 PM UTC

fdomig wrote: post #14

From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org

Post by sonyandy » Tue, Nov 18, 2014, 10:20 PM UTC

ufo wrote: post #54

slashnull wrote: post #31

At last! This all seem extremely cool. I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I've always found that my code, and a lot of good libraries I read, naturally emulate something close to Hindley-Milner typing, by using objects as tuples/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Ei…

You can't really use sum types as they are found in Haskell in Javascript. With Haskell option types you do a pattern matching and create a new binding for the non-null value but in Javascript you don't do that - you keep using the same object that you tested against null. case mx of Just x -> f(x) vs if (x != null){ f(x) } What you can do in a Javascript-like language is use union and intersection types. However, th…

  function nothing() {
    return {
      match: function(cases) { return cases.nothing(); }
    };
  }

  function just(x) {
    return {
      match: function(cases) { return cases.just(x); }
    };
  }

  just(1).match({
    just: function(x) { return x + 1; }
    nothing: function() { return 0; }
  });