For me it's typically weighted less on the type system and more the fact that I don't need to wait for a compiler or use any fancy tools to get a quick idea realized.
I’ve been developing with compiled languages since the early 90s and even with a computer of that era, compiling within a decent IDE hasn’t slowed me down.
If you remove a lot of the cruft and redundancy and add memory management, a statically typed language with fast compiles can have some of the benefits of a dynamic language.
If I could have a dynamic language, and static typing, that would be the best of both worlds. However, gradual typing doesn't seem to have caught on.
Gradual typing has a strong tendency to turn into never-typing because when you've got it running there is no real point to going back and adding types. Which divides people back into those who want dynamic typing and those who want static typing.
Tracing JIT VMs gather the information on what the types actually are at runtime. I wish that such JIT VMs running server software would gather such information, which could then be automatically applied.
The JIT VMs gather that information, but then are careful to hide all of the typed calls behind run-time checks for the validity of the types. Failing to do so is an invitation to create bugs on rare use cases that didn't happen to be in your run. Making those code changes either results in duplicated auto-generated code that nobody looks at, or results in a source of possible bugs.
To give a concrete example, suppose that you have a weighted graph whose weights are integers. Code to find a Minimum Spanning Tree will always have an integer for the weight. Great. But if you add that type annotation, you'll run into trouble when someone checks whether the previously found MST is unique by calling the same algorithm again using as weights (weight, edges_in_common_with_prev_mst). (This will find the MST that shares as few edges as possible with the original, so if there are > 1 you'll find a different one.)
Those ordered pairs were just fine in the original code, but don't fit the type annotation.
The JIT VMs gather that information, but then are careful to hide all of the typed calls behind run-time checks for the validity of the types. Failing to do so is an invitation to create bugs on rare use cases that didn't happen to be in your run. Making those code changes either results in duplicated auto-generated code that nobody looks at, or results in a source of possible bugs.
Of course, you want to use data correctly. There was a study of server code in Python that found that lots of playing fast and loose with type information happens just after startup, but then types settle down. If the initialization can be isolated in certain parts of the code base, it would make such date easier to use.
With C# you can mix dynamic and static to some degree. In some cases like parsing JSON dynamic code can be much shorter. But for maintainability the dynamic code parts should be kept localized and to a minimum/
I don't find myself actually using gradual typing though. Not very often at least. Even in prototypical stages of an application, I usually just put together the types of what I currently have, even if I think they will change later.
Typescript is pretty similar to C# from what I can tell. Not a surprise considering that the designer is the same.
I have found it very useful for things like translating incoming JSON or XML to the typed world. As long as the input data is of known format dynamic code is much shorter and concise.
I think this fits squarely into the “rapid prototyping” scenario. Perhaps if you had to design your software to very tight constraints you might find static typing to be a productivity boost.
