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).

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.