I digress but...

you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibility in the language for little gain. And I feel like the reason I never hit type issues, is because I write full test coverage, which in turn make it painfully obvious what is and is not expected in each method.

For the reasons above, I love the idea of this tool dynamically checking all my code paths, and looking for things that are likely mistakes or result in null exceptions.

But I'm afraid to recommend this to my boss, for fear that for now on, everything must be maximum static... everything annotated, no union types, etc.

Just my 2 cents.

Misspelled variable names might not be something you'd classify as a "type error" but that can't happen with static typing. "Undefined is not a function" is in essence a type error and i really doubt you've never ever seen that.

Static typing also serve as a documentation, and enables "intellisense-coding" without having to google documentation every 2 minutes. Take this function signature from pythons standard library: subprocess.Popen(args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=())

Without documentation, can you answer: what is env? what is stdin? what values are allowed in creationflags? is it obvious that startupinfo should be a STARTUPINFO object?

Compare to a C# equivalent, FileStream Open(string path, FileMode mode, FileAccess access, FileShare share). Here it is obvious that FileAccess can only have one out of 3 available options in the enum since the autocomplete will only give you those three options.

I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal.

Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection.

I can't remember one example of type error where I intended to call method on MyClassA and ended up trying to call it on MyClassB. But that may be the effect of my coding style (I'm not big fan of class hierarchies in js).

And in a large app it is hard to know if all relevant code has ran. Finding pieces that uses the code you just changed is much easier in static languages. We might not go to a fully statically typed javascript but supporting optional typing seems like a really good idea.

Yes I know, I mostly work in java these days.

BTW it's funny how many times late binding was reinvented in j2ee ecosystem :)

But JS does not have compile-time - you edit it, and you run it, no steps in between. If set up right you've got your unit tests running automatically whenever something changes.

I have written a couple of thousand lines in an app the last year and I have already had problems with restructuring my app. Creating new modules and moving "classes" into them or splitting classes and renaming them are very useful things and those things get easier with types. Having tests actually don't help that much with this in my opinion since I have to rewrite the tests also. Also reading old code could get easier with some type information in the code. Just my experience so far.

Absolutely. I used to use hungarian notation in a static language because I was so scared of getting the wrong type. It was a huge revelation that actually this never happens.

However, whilst I never hit on basic type errors such as passing a string when I need an int - I regularly come across object type errors. I'll pass an object with a project_id property to a method that actually expects an id property. Not sure if flow can handle these - if it could it would be pretty amazing.

All the time, in my case.

Today I got the order of parameters to a callback wrong ("error" was the last rather than the first parameter). The documentation didn't say anything about parameters, it only said that the callback would be called with a result. I had to look into the source code to discover the details. I am not sure if Flow would be able to catch this kind of bug but if so, it would certainly save me a lot of time.

In the large multi-contributor dynamically-typed codebases I've dealt with, type errors are very rare.

I don't think you understand what "type errors" means if you are making that assertion; or your multi-contributor codebase has such excellent test coverage that your tests are doing for you what a modern type system can do for you.

In a dynamically-typed codebase, it's near impossible to have rare type-error occurrence because you're off-loading the type system into into the programmers head (which is subject to human fallibility - even when countered with excellent unit testing!)

To be specific, I was talking only of a specific sort of errors that the JIT compiler allows e.g. applying numerical operators to strings, or combinations of string and int.

Issues with null are much more common.

In JS, I see things like methods called with incorrect number of parameters, or wrong parameter types, on a reasonably regular basis, especially when things get refactored every now and then.

I frequently see methods incorrectly overidden. For example, the ancestor method effectively has a variadic argument list, but the descendant doesn't have as sophisticated argument handling and doesn't do the appropriate superFunc.apply(this, Array.prototype.slice.call(arguments, 0)) etc.