> In fact, on the contrary, strongly typed systems have better type inference allowing fewer annotations, particularly for consumers of APIs that are typed.
The number of type annotations required for configuration code can't be less than zero, which is what I'd expect with Nickel.
My impression of how verbose a totally statically typed system might be for this is mostly based on what I've seen of Dhall and heard about it, which may not be fair, idk.
But the idea is that Nickel can be used for configuration code that any sysadmin would be used to writing because it might as well be JSON or YAML. This is what motivates the library/configuration distinction:
> Nickel also aims at being as interoperable with JSON as possible, and dealing with JSON values in a typed manner may be painful. For all these reasons, being untyped1 in configuration code is appealing.
> But this is not true of all code. Library code is written to be reused many times in many different settings. Although specialised in configuration, Nickel is a proper programming language, and one of its value propositions is precisely to provide abstractions to avoid repeating yourself. For reusable code, static typing sounds like the natural choice, bringing in all the usual benefits.
https://www.tweag.io/blog/2021-03-18-nickel-gradual-typing/
The Nickel docs currently cite other reasons as the main motivation for choosing gradual typing:
> For pure configuration code, consisting predominantly of data, static typing is perhaps less useful than in other kinds of application. Firstly, a configuration is a terminating program run once on fixed inputs, so basic type errors will show up at runtime. Secondly, for data validation, static types are too rigid. For example, statically checking that an expression will always evaluate to a valid port number requires very advanced machinery. On the other hand, checking this property at runtime is trivial.
https://nickel-lang.org/user-manual/correctness