There's conflict of interests. Errors are exceptional cases in simple or
one-timer run programs and could be ignored. Errors are not exceptional cases
for long running programs and could not be ignored.
There are no way to satisfy both use cases (actually, Erlang did it by
assembling program as independent isolated chunks, but Erlang approach is not
possible for languages with shared memory).
I think simple cases are very important and should be kept simple, and complex
cases possible. And, Nim (and Java, Python, Ruby etc.) went that way. Go
decided differently, to make simple cases harder but complex cases easier, but
that path is not for everyone.
I think `{.raises: [].}` at the top of the module is a reasonable way.
>From my personal experience, this problem is magnified by async. Async itself
>is harder, but in simple language like JavaScript when everything is made
>specifically for async, it's more or less ok. But when you try to combine
>async + Nim (a very complicated language with many different concepts) +
>immature platform. It's like 3x more complicated and became unmanageable.
> ... Sure, in Go you have to write the error logic by yourself, but that's not
> difficult ...
It is difficult and annyoing. In cases when you don't need it.
