Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Launches Flow, Static Type Checker for JavaScript

code.prod.facebook.com

Post reply on HN
Print view View original

131–140 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#131

Post by krapp »

aliakhtar wrote: post #126
krapp wrote: post #116

Earlier quoted context omitted.

"Java" which "compiles" to javascript is not Java. It's javascript with a ludicrous amount of syntactic sugar applied.

All the language features of java: generics, inheritance, type safety, interfaces, and soon to come: lambdas and other Java 8 features, are all supported. Plus your code is organized in java packages. So, I'm not sure you've ever tried GWT. Things like multi threading which aren't possible in javascript aren't supported, but a lot of the JRE which is used in most code, does come out of the box. Its a huge improvement…

Those are features of the IDE, and of Java, certainly. But type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different.

What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't really implement it.

I'm not saying it isn't a useful tool, or that the javascript it generates isn't far, far superior to anything I could roll on my own - but...

>Things like multi threading which aren't possible in javascript aren't supported

...it isn't Java.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#132

Post by Shizka »

cdelsolar wrote: post #129
kulkarnic wrote: post #127

Earlier quoted context omitted.

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…

Read the Good Parts of Javascript and get a JS linter. Javascript is a fine language if you do this.

I've had the exact same concerns as the person you replied to. I just want to make sure since the title differs from the one you stated. Is this the book you were talking about: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#133

Post by lhnz »

kulkarnic wrote: post #127
DigitalSea wrote: post #39

What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React…

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…

You are right that there are some problems in the language. However, I would rethink your argument based on the rapid development of the language over the last 5 years.

For example, yes callbacks were very messy but very soon we will have generators. And, yes, the scoping was nasty but soon we will have the 'let' keyword. I cannot remember where I read it, but I do also remember seeing a talk about some proposals to extend "use strict" to allow people to fix some of the type-casting behaviours made infamous by wat, too.

My point isn't that everything is fixed and we can stop complaining about the bad parts. My point is that it is very impressive how those in charge are handling the evolution of the language.

I think it's worth taking a bet on a language which improves so much every year.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#134

Post by slashnull »

tel wrote: post #118
slashnull wrote: post #56

Earlier quoted context omitted.

I don't want to say what I'm about to say, but... I don't care about the type signature of promises. I actually don't care about the type of anything which has a complicated type; I think it's just incredibly winning that I will now be able to describe the shape of the raw data circulating in my code. I've always found really annoying, in Haskell, to see incredibly complex type idioms emerging to allow stuff that doe…

I'd like to argue from a Haskell backend perspective that monad transformers deserve exactly the complexity they expose. They give you a handle to factor side effects in sensible ways and to express that code requires exactly some set of effects and no others. It is not always clear how to factor code which does not have this rigor into effect-typed form. It can be extraordinarily difficult to recognize what effects…

... said the monk, sitting cross-legged with an air of zen inner peace ; )

I think it all boils down to considerations of idealism vs. realism, in the end, and yes, I have to admit, I managed to get a sort of big picture understanding of Yesod and its ORM, and it's definitely a cool design. Can't say I know as much about Happstack, but the hello worlds were smaller. And the authors didn't have to invent two dependency management tools to get it to compile... /off-topic

I actually used something akin to monads to write a quick and dirty parser combinator library... In PHP! It was really fun, but I have to admit that it got really hard to keep track of what was function, what was return, what was supposed to be passed along to the next function and so on without any real typing. For the first time I... I wanted monads.

But still, I have 99 problems and I'd say 97 of them are undefined, nulls, erroneous typecasts, unexpected layers of wrapping, and so on. I wrote bad code, my teammates did, and here we are. I want to get rid of those so that I can, at last, have real problems.

Then I'll port my REST server in Haskell ; )

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#135

Post by discreteevent »

ep103 wrote: 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 design from the code.

This tool claims it can do advanced inference. If it were possible to hook it up to an editor or IDE to analyse existing untyped js in this way it could be invaluable.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#136

Post by spion »

kulkarnic wrote: post #127
DigitalSea wrote: post #39

What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React…

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…

ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity. And there is `let` which has a "normal" scope, although I'm not really sure it needs that. Additionally, generators let you use normal control flow constructs for IO, if you prefer that to FP.

While its no Haskell, it certainly isn't much more verbose than other dynamic languages anymore. And a typesystem like TypeScript or Flow pretty much eliminates the rest of the gotchas.

Off the top of my head, there are two embarrassing holes: bigger integers and parallelism. Can't think of anything else at the moment (macros maybe, but they're a double-edged sword wrt tooling). Wonder if anything else is missing?

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#138

Post by slashnull »

aikah wrote: post #137

I'm really curious about the accuarcy of that tool,really really curious given how javascript "types" work.

JavaScript actually has a pretty small number of type primitives; I'd say that the bad rap about JS's typing is due to the absolutely mind-boggling type conversion rules (which are nevertheless part of the specification).

Even if that wasn't the case, their design just avoids the issue by not trying to do any typecast, ever.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#139

Post by hrktb »

kulkarnic wrote: post #127
DigitalSea wrote: post #39

What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React…

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…

> JS the language of the future? [...]I can certainly see being stuck with Javascript

I think we all agree. JS has very ugly things, but it isn't going anywhere for the forseeeable future.

If we're going to use for at least a few more years, I'd applaud anyone making better tools and rejoice when I see better frameworks and easier to use libraries.

Now by the time alternatives to javascript become viable, we might have made javascript something way better than what we already have now. It could survive a long long time and with people actively making it evolve, and it could be very enjoyable. Who knows.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#140

Post by Touche »

arjie wrote: post #106
Touche wrote: post #102

Earlier quoted context omitted.

I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain? I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception. I get the benefit of optional type checking without a compile step in development like with Flow.

Well, I assumed you'd want to spot that error before it happens rather than when it does. The exception being thrown by the assert (at run-time) means that the user sees the failure. That's sub-optimal, right? So you'd ensure that there is testing of all code that calls this code in order to trigger the exception ahead of time if that occurs. Or am I misunderstanding? It just seems that the assert applies the constra…

I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated.

Sure it's less certain than what you get from a compiler; that's the tradeoff for not having to compile in development. Since most JavaScript code is not type-sensitive it's only important in code that you are more than likely going to be testing heavily anyways.

Post reply on HN