Live data from Hacker News

Facebook Launches Flow, Static Type Checker for JavaScript

code.prod.facebook.com

251–260 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#251
post #164

Earlier quoted context omitted.

>type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different. You are not coding in javascript. You are coding in java, and the code is then converted into highly efficient javascript by a compiler. > What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't re…

I don't think you're seeing my point. You may be coding java, but none of the tangible benefits of java over javascript actually translate, because you're actually writing javascript, with all of the warts and limitations and weirdness therein. The javascript exported will not be truly type safe, because javascript is not, and cannot be. It may appear to act like it, within the context of the code when run as predict…

The point is, that you don't have to deal with any of those issues with javascript. I've been using GWT for over a year, and I've never had to dive into the compiled javascript to debug something. I only ever edit my java code, and I compile it, that's it. Its exactly the same as your C code compiling to assembly, or the java code compiling to bytecode. You never have to look at the compiler's output.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#252

Whatever people's thoughts on the language itself, JavaScript has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast. It helps that companies like Google and Facebook have invested a significant amount of…

"Whatever people's thoughts on the language itself, Java has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast. It helps that companies like Google and Oracle have invested a significant amount of research power into designing frameworks and tooling around it. Just from there two companies alone, we have tools like GWT, Android, MySQL..."

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#253

Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…

> in my experience, type related errors are usually easy to find and fix and have rarely if ever been the root cause of our most difficult problems.

In a language without a strong type system you rarely appreciate quite how many of your invariants could be lifted into the type system. When I wrote Python most of my errors didn't seem like type errors (e.g. I remember forgetting to close a connection and so leaking connections), but now that I write Scala I can see how I'd structure my program using types so that that would be a type error (I'd use monads to compose the idea of an operation that uses a connection, and then execute them in one place).

(Python now has an ad-hoc fix for this specific problem in the form of the "with" statement, just as 3.4 adds an ad-hoc fix for the proliferation of different ways of doing async calls. But a good type system is a general solution to both these problems and more).

> Dynamic type checking and implicit conversion is one of the more powerful features of JavaScript

In a strongly typed language you can do this in a controlled way; it can be part of the language, and can apply equally well to user-defined structures. Whereas with Javascript you're stuck with those implicit conversions built into the language, and if you want to convert e.g. an address datatype, you're out of luck.

> certainly no less prone to error or counter-productive than type-casting, making variadic functions or class templates are in other languages.

Then use a language that doesn't have those problems either. There are good languages out there - if Scala isn't for you then how about OCaml or Haskell?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#254
post #68

This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language. That said, I am curious what solutions this solves that isn't already solved by enforcing good code…

The main benefit of types for me is not correctness but documentation and tooling. It's fine not to have types in code I write myself or with one or two others. But if I have to deal with a large codebase that I wasn't involved in writing then types make it so much quicker to understand. Just being able to quickly find all references to a type or all a method's call sites makes it possible to "reverse engineer" the d…

you should check out sublime text if you haven't already. ST3 reads your js as you type it, and allows you to navigate through the code like you would through visual studio, keeping a dictionary of where the words appear and guessing what they are as. Its not as good as a static languages navigational abilities (you may have to choose between jumping to Increment the function, and Increment the variable), but its still pretty good.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#255

Whatever people's thoughts on the language itself, JavaScript has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast. It helps that companies like Google and Facebook have invested a significant amount of…

Working on an app recently for Android & iOS. Cordova helped us leverage a lot of existing skills in our team, and definitely made a lot of things easier. Changes not having to be implemented twice per platform for example. But one would run into some really weird bugs, and tricky things to debug now and then. Overall i'd say it was worth it, but hybrid apps definitely have their caveats.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#256
post #197

Earlier quoted context omitted.

May I ask why? Not having parallelism seems like a net negative to me...

[Edit] Before starting, I just want to state: I know JavaScript has parallelism/concurrency in its supporting "system calls" (ie what would, in other languages, be blocking calls, in both the browser or Node). In fact I like this parallelism model, but I was specifically talking about parallelism built into the language (Threads, Actors, Tasks). This is a long and complicated answer. I doubt I'll do it justice in a f…

This is an interesting point of view. I personally find the erlang approach -no shared memory- to be the least error prone, and as a consequence the most efficient for developers.

With Erlang you can't share memory [0], but in exchange you get sequential code (no callbacks or yields), true parallelism, and even distribution over a cluster. With node.js all the asynchronous calls live in the same memory space, but code is written with nested callbacks (or yields), and of course you get no parallelism.

[0] There are shared dictionaries for when it is really absolutely necessary.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#257
post #252

Whatever people's thoughts on the language itself, JavaScript has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast. It helps that companies like Google and Facebook have invested a significant amount of…

"Whatever people's thoughts on the language itself, Java has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast. It helps that companies like Google and Oracle have invested a significant amount of researc…

I don't really see the Java ecosystem as comparable - sure, there's a lot of stuff, but I haven't seen nearly as much as in JS.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#258
post #185

Earlier quoted context omitted.

Hmm, so assembly code doesn't have any type safety or high level features. So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? What a load of crap and the op is down voted!!! You are writing java and barring some features like multi-threading,…

>So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? Javascript is not the equivalent of assembly. Javascript is, itself, a higher-level language. You're talking about translating from one high-level language to another, and expecting the inte…

> You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former.

Actually, no, you aren't. The compiler cares about the rules of the language being compiled. The interpreter of the target language doesn't have to care, because code that violates the rules isn't output by the compiler. There's nothing special about high-level languages as a target, its exactly the same situation as any compiler for any general purpose machine (the only thing that might be different is a compiler for a language-specialized VM, but even for those generally many rules of the language aren't present in the VM and exist only in the compiler.)

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#259

Who writes JS these days? Will it go with Angular/jQuery?

Angular and jQuery ARE JavaScript.

It probably doesn't typecheck yet though. Will future versions of popular javascript libraries typecheck with flow, or will there be a repository of interface files so at least code using these frameworks can typecheck?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#260

Can someone explain in simple words what is the problem that this would fix? I've never felt the need for this, why should I care?

It makes it easier to catch some types of bugs without having to run the code.

http://en.wikipedia.org/wiki/Type_system#Static_type-checkin...

Post reply on HN