5 ms·

> Lack of exceptions Go does support multiple return values, commonly (T, error). If you think about it for a while, you will realize a exception is just a typ

> Lack of exceptions Go does support multiple return values, commonly (T, error). If you think about it for a while, you will realize a exception is just a type of return value. 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 https://github.com/cheekybits/genny

dom96 9y ago
> 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 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.
- kskskuejej2 9y ago
  > 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
nimmer 9y ago
> 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-procs-with-raised-exceptions https://nim-lang.org/docs/tut2.html#exceptions-annotating-pr...
- kskskuejej2 9y ago
  And golang knows what type of error can be returned at compile time. type FatalError error func foo() FatalError {}
  - dom96 9y ago
    Nim does too. The exception tracking is performed at compile time.
Twey 9y ago
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.

dom96 9y ago

> 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 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.

kskskuejej2 9y ago
> 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

nimmer 9y ago

> 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-procs-with-raised-exceptions https://nim-lang.org/docs/tut2.html#exceptions-annotating-pr...

kskskuejej2 9y ago
And golang knows what type of error can be returned at compile time. type FatalError error func foo() FatalError {}
- dom96 9y ago
  Nim does too. The exception tracking is performed at compile time.

Twey 9y ago

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.