6 ms·

So, there is a trend to build static type checker for popular managed dynamic languages? Facebook also built Flow, a type checker for Javascript [1]. [1] http

So, there is a trend to build static type checker for popular managed dynamic languages? Facebook also built Flow, a type checker for Javascript [1]. [1] https://flow.org/ https://flow.org/

lacksconfidence 8y ago
They also transformed php into a very similar language (hacklang) and built a type checker for that.
m0meni 8y ago
Also they're rewriting messenger in basically OCaml (Reason[0]) i.e. a statically typed FP language. [0]: https://reasonml.github.io/ https://reasonml.github.io/
- dons 8y ago
  And "eradicate" for Java... http://fbinfer.com/docs/eradicate.html http://fbinfer.com/docs/eradicate.html we love types. They help us ship stuff faster.
- laylomo2 8y ago
  This should be upvoted higher. ReasonML is a fantastically beautiful language.
  - weberc2 8y ago
    Yeah, it just needs to work on its tooling and library story. Last time I tried, the OCaml toolchain was such a big pain that the Reason community basically told me to give up and compile to Node. And then there are relatively few native-ReasonML libraries, so you have to figure out how to integrate with OCaml which usually means learning how to _read_ OCaml without clawing your eyes out (I'm only sort of joking). I'm rooting for Reason, but it has a few nontrivial hills to climb before it's practical.
    - Rotareti 8y ago
      I find it already very practical for web frontend work. Editor support is great if you use VSCode.
      - weberc2 8y ago
        That's encouraging to hear. Unfortunately I don't do much frontend web development, but hopefully if the frontend web-dev story catches on then the backend will follow.
GordonS 8y ago
It does beg the question: why not use a statically typed language in the first place?
- m0meni 8y ago
  With flow, you just gradually add typings and fix the resulting type errors. It's way easier to slowly integrate types file by file rather than rewriting everything. Moreover I think that at the time there were no statically typed languages that targeted web.
  - camdenreslink 8y ago
    Java has targeted the web since forever. Ditto for C#.
    - m0meni 8y ago
      By target web, I meant compile to js with good interop. I.e. no languages like elm, purescript, reason, ghcjs, kotlin, etc.
      - zenhack 8y ago
        Reason/ocaml-bucklescript's js interop is actually very good -- it's one of the nicest FFIs I've ever seen.
- bastawhiz 8y ago
  If the question is "why choose Python" or "why choose JavaScript", then I think you're missing the point. Python is simple and beautiful and highly productive to work in. JavaScript is ostensibly the only language that you can use in the browser without a compilation step (to JavaScript). Just because typing is added separately doesn't negate all of the other benefits of these languages. Hell, if all programmers cared about was type safety we'd all be writing Rust for every project.
  - 8y ago
sidcool 8y ago
How's people's experience with Flow?
- m0meni 8y ago
  JS with flow is way better than JS without flow. It prevents a whole class of errors, and you can basically opt-in and opt-out of the type system at any time if you're having trouble with it too. I wrote a blog post about it a while back: https://www.aria.ai/blog/posts/why-use-flow.html https://www.aria.ai/blog/posts/why-use-flow.html That being said, while I started out using Flow, TypeScript just has way more community adoption and better tooling. So at this point, I usually recommend TS over Flow to most people. But using either of them is way better than writing just regular JS code.
- Epskampie 8y ago
  Typescript has way better editor support, and is faster on large projects. Flow is mostly terminal only, and required a really annoying syntax in it's config file to exclude all node modules. That being said, Flow is better then no typechecks, and it was half a year ago that I looked, stuff might have improved.
- xab9 8y ago
  TS > flow.
- ggregoire 8y ago
  I'm using Flow but I'd recommend TypeScript. I love Flow but TypeScript just seems to be more seriously maintained and less buggy. I've been waiting some bug fixes for 2 years (like all the object destructing and spread issues[1]), but they prioritize the Facebook private internal roadmap before anything else (like they improve the performances in almost every patch, but it's useful only for FB and its millions of lines of code). So yeah, the support is kind of inexistent and it's frustrating. When you find a bug, you have to rewrite your code in another way to workaround… On the other hand, I don't agree with some of the comments here. For example, Flow is not terminal only at all, I never use the terminal to run Flow. The editor integration is totally fine, especially in Atom and VSCode. [1] https://github.com/facebook/flow/issues/2405 https://github.com/facebook/flow/issues/2405
sametmax 8y ago
For Python it makes a lot of sense. It's a language that let you start small, and progress a lot with the complexity of your code. You can be productive in Python in 3 days if you know another language. But you can still learn new Python useful things 10 years after you started. The progress curve is very sane. And in the same way, your project may start small, then you add docstrings, classes, modules, packaging, unittests, infrastructure... And at some point, you may want types. I use types on maybe 10% of my code in Python. It's great it's not mandatory. And it's great it's here when I benefit from it.
- weberc2 8y ago
  I write Python in my day job and I _always_ start with types. I find they make even prototype code so much easier to reason about. It's just nice to be able to tell at a glance what a function returns, what args it takes, etc., and I don't have to master Sphinx's cryptic syntax (which I still haven't managed after using it for 5 years). And I experience this benefit even for code that I wrote yesterday without even running the type checker. And it's only going to get better with editor integration. Without types, if I have the code `a = foo(x=1)` then I have to hunt down the source file for `foo()`, which likely just returns `bar(x)`, so I have to hunt down the source file for `bar()` to figure out what the hell its return type is, and so on and so forth. With types, I just look at the type signature for `foo()` and I'm good to go (and again, editor integration means that I don't even need to look up `foo()` at all!). YMMV.
  - sametmax 8y ago
    > I write Python in my day job and I _always_ start with types. It depends of the project. If you write a lot of flask/django code, writing the types is not that worth it except for a few functions/methods. > Without types, if I have the code `a = foo(x=1)` then I have to hunt down the source file for `foo()` No, you just hover the function and get the help() out of it in most framework and libs. Again, if your code is mainly using a well define, documented and popular framework/lib/api, that's not a big deal. And it certainly doesn't require YOU to add types. Or if you write a program that is contained in 1 to 5 files top. Not use for types. Or if you are writing your program in jupyter. And you most likely copy a snipet from the doc anyway. After all, if you see that the function you want to use return a AbstractTranscientVectorServiceFactory object, you can't do much with the information without the doc anyway. But let's be real, most functions in Python are named pretty explicitly, and return things that you expect like "iterable of numbers" or "file like object yielding utf8". Types are particularly useful in the cases if you are in a big project with a lot of custom code or in a domain either very complex or that you don't master very well. They are a good for of safety net and documentation at the same time. But they come at a cost and it's a good thing to be able to choose.
wvenable 8y ago
PHP has static type checking now, as well.

So, there is a trend to build static type checker for popular managed dynamic languages? Facebook also built Flow, a type checker for Javascript [1]. [1] https://flow.org/ https://flow.org/

lacksconfidence 8y ago

They also transformed php into a very similar language (hacklang) and built a type checker for that.

m0meni 8y ago

Also they're rewriting messenger in basically OCaml (Reason[0]) i.e. a statically typed FP language. [0]: https://reasonml.github.io/ https://reasonml.github.io/

dons 8y ago
And "eradicate" for Java... http://fbinfer.com/docs/eradicate.html http://fbinfer.com/docs/eradicate.html we love types. They help us ship stuff faster.
laylomo2 8y ago
This should be upvoted higher. ReasonML is a fantastically beautiful language.
- weberc2 8y ago
  Yeah, it just needs to work on its tooling and library story. Last time I tried, the OCaml toolchain was such a big pain that the Reason community basically told me to give up and compile to Node. And then there are relatively few native-ReasonML libraries, so you have to figure out how to integrate with OCaml which usually means learning how to _read_ OCaml without clawing your eyes out (I'm only sort of joking). I'm rooting for Reason, but it has a few nontrivial hills to climb before it's practical.
  - Rotareti 8y ago
    I find it already very practical for web frontend work. Editor support is great if you use VSCode.
    - weberc2 8y ago
      That's encouraging to hear. Unfortunately I don't do much frontend web development, but hopefully if the frontend web-dev story catches on then the backend will follow.

GordonS 8y ago

It does beg the question: why not use a statically typed language in the first place?

m0meni 8y ago
With flow, you just gradually add typings and fix the resulting type errors. It's way easier to slowly integrate types file by file rather than rewriting everything. Moreover I think that at the time there were no statically typed languages that targeted web.
- camdenreslink 8y ago
  Java has targeted the web since forever. Ditto for C#.
  - m0meni 8y ago
    By target web, I meant compile to js with good interop. I.e. no languages like elm, purescript, reason, ghcjs, kotlin, etc.
    - zenhack 8y ago
      Reason/ocaml-bucklescript's js interop is actually very good -- it's one of the nicest FFIs I've ever seen.
bastawhiz 8y ago
If the question is "why choose Python" or "why choose JavaScript", then I think you're missing the point. Python is simple and beautiful and highly productive to work in. JavaScript is ostensibly the only language that you can use in the browser without a compilation step (to JavaScript). Just because typing is added separately doesn't negate all of the other benefits of these languages. Hell, if all programmers cared about was type safety we'd all be writing Rust for every project.
- 8y ago

sidcool 8y ago

How's people's experience with Flow?

m0meni 8y ago
JS with flow is way better than JS without flow. It prevents a whole class of errors, and you can basically opt-in and opt-out of the type system at any time if you're having trouble with it too. I wrote a blog post about it a while back: https://www.aria.ai/blog/posts/why-use-flow.html https://www.aria.ai/blog/posts/why-use-flow.html That being said, while I started out using Flow, TypeScript just has way more community adoption and better tooling. So at this point, I usually recommend TS over Flow to most people. But using either of them is way better than writing just regular JS code.
Epskampie 8y ago
Typescript has way better editor support, and is faster on large projects. Flow is mostly terminal only, and required a really annoying syntax in it's config file to exclude all node modules. That being said, Flow is better then no typechecks, and it was half a year ago that I looked, stuff might have improved.
xab9 8y ago
TS > flow.
ggregoire 8y ago
I'm using Flow but I'd recommend TypeScript. I love Flow but TypeScript just seems to be more seriously maintained and less buggy. I've been waiting some bug fixes for 2 years (like all the object destructing and spread issues[1]), but they prioritize the Facebook private internal roadmap before anything else (like they improve the performances in almost every patch, but it's useful only for FB and its millions of lines of code). So yeah, the support is kind of inexistent and it's frustrating. When you find a bug, you have to rewrite your code in another way to workaround… On the other hand, I don't agree with some of the comments here. For example, Flow is not terminal only at all, I never use the terminal to run Flow. The editor integration is totally fine, especially in Atom and VSCode. [1] https://github.com/facebook/flow/issues/2405 https://github.com/facebook/flow/issues/2405

sametmax 8y ago

For Python it makes a lot of sense. It's a language that let you start small, and progress a lot with the complexity of your code. You can be productive in Python in 3 days if you know another language. But you can still learn new Python useful things 10 years after you started. The progress curve is very sane. And in the same way, your project may start small, then you add docstrings, classes, modules, packaging, unittests, infrastructure... And at some point, you may want types. I use types on maybe 10% of my code in Python. It's great it's not mandatory. And it's great it's here when I benefit from it.

weberc2 8y ago
I write Python in my day job and I _always_ start with types. I find they make even prototype code so much easier to reason about. It's just nice to be able to tell at a glance what a function returns, what args it takes, etc., and I don't have to master Sphinx's cryptic syntax (which I still haven't managed after using it for 5 years). And I experience this benefit even for code that I wrote yesterday without even running the type checker. And it's only going to get better with editor integration. Without types, if I have the code `a = foo(x=1)` then I have to hunt down the source file for `foo()`, which likely just returns `bar(x)`, so I have to hunt down the source file for `bar()` to figure out what the hell its return type is, and so on and so forth. With types, I just look at the type signature for `foo()` and I'm good to go (and again, editor integration means that I don't even need to look up `foo()` at all!). YMMV.
- sametmax 8y ago
  > I write Python in my day job and I _always_ start with types. It depends of the project. If you write a lot of flask/django code, writing the types is not that worth it except for a few functions/methods. > Without types, if I have the code `a = foo(x=1)` then I have to hunt down the source file for `foo()` No, you just hover the function and get the help() out of it in most framework and libs. Again, if your code is mainly using a well define, documented and popular framework/lib/api, that's not a big deal. And it certainly doesn't require YOU to add types. Or if you write a program that is contained in 1 to 5 files top. Not use for types. Or if you are writing your program in jupyter. And you most likely copy a snipet from the doc anyway. After all, if you see that the function you want to use return a AbstractTranscientVectorServiceFactory object, you can't do much with the information without the doc anyway. But let's be real, most functions in Python are named pretty explicitly, and return things that you expect like "iterable of numbers" or "file like object yielding utf8". Types are particularly useful in the cases if you are in a big project with a lot of custom code or in a domain either very complex or that you don't master very well. They are a good for of safety net and documentation at the same time. But they come at a cost and it's a good thing to be able to choose.

wvenable 8y ago

PHP has static type checking now, as well.