At this point it is not possible to claim that static type systems definitely provide benefits on their own. However it's also rare to find counter-examples of when having a dynamic type system is a concrete benefit. So here's one.

In DiscordRC, user commands can take CLI-style options that are parsed with yargs. The produces a dictionary with the option names as keys.

Being a big fan of functional programming, the vast majority of the application is composed of reusable functions. One of these is searchLogs() which takes as its second argument an options object that can have any number of query-modifying options such as --nick, --ident, --hostname etc.

When adding the ability to plot user messages over time, searchLogs() was a natural target for reuse and indeed was reusable here. The plotting user command also honors options of its own, sourced from the same options object passed into it from the command runner.

Now here's the payoff: in a statically-typed language, this options object would be strictly defined to have a set of fields with given types, meaning that unless it was a grab-bag definition of every possible field it would not be passable from the user command to searchLogs() wholesale: it would require an intermediate transform, at very least.

However, because this is a dynamic language, the same options object can be passed to downstream functions at liberty and without any extra machinery. By virtue of this & without even realizing it at first*, the plotting command automatically supported the additional query options supported by searchLogs() such as --ident and --hostname without changing a single line to enable that support. This is simply impossible in a statically-typed language (without using escape hatches like any/void* etc.), and let's be honest is a pretty good advertisment for functional programming too.

* A suprisingly delightful realization. When was the last time you were surprised and delighted as you worked with a language (not by the language itself)?

P.S. Yes, this post is deliberately titled with a play on "type safety" to intentionally deride the connotation that the opposite must be "dangerous". Hence why the actual post only uses the proper, well-defined terms "static" and "dynamic". (Also not "strong" and "weak", which again suffer from the same problems of weak definition & connotation!)