Sure, they are, but they're sums, not products. Go's failure to acknowledge this leads to infecting every type with the Billion-Dollar Mistake in an effort to encode sums as products (and loses out on compiler checking of it, in the process). The syntactic aspect of exceptions is nice, but can be handled without compiler magic if you have nice syntax for monads in general.

> Go does support multiple return values, commonly (T, error).

Sure, and Nim supports multiple return values too. But having to handle this extra value at every function call seems like it would get old really fast. I don't want to worry about every single exception when I am prototyping for example. Also, without stack traces, how do I know where an error comes from?

> Regarding generics, the more I used golang, the less I had a need for generics. Also, there is solutions if you insist, such as https://github.com/cheekybits/genny

Indeed, like I said, I haven't used it much so perhaps I would be able to live without generics. It is still very nice that Nim offers them though.

> I don't want to worry about every single exception when I am prototyping for example.

You are free to ignore the returned error, so for example to compare with a situation where you would raise an exception in another language inside a function, but not wrap the call in a try-catch:

val, _ := funcThatCanFail()

> Also, without stack traces, how do I know where an error comes from?

Go does have stack traces

> exception is just a type of return value

No, they are part of the syntax. The compiler (in Nim and other languages) can track which exceptions are allowed to be raised in a procedure and which aren't at compile time:

https://nim-lang.org/docs/tut2.html#exceptions-annotating-pr...

And golang knows what type of error can be returned at compile time.

    type FatalError error
    func foo() FatalError {}

Nim does too. The exception tracking is performed at compile time.