Thanks for being honest with everything, I found this to be a very balanced answer.
What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements.
What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements.
> What would you say are the advantages of Nim over a language like Go? I see a lot of similar "value add" statements.
In all fairness I haven't given Go a proper try. But my main problems with it, based on what I've seen of it, are the following:
* Lack of generics
* Lack of exceptions
* I prefer the Python-like syntax of Nim
* Metaprogramming in Nim is fun and powerful
* Lack of (official) package manager
* Lack of generics
* Lack of exceptions
BTW C/Go/lua are my languages of choice
I don't like Go's explicit error handling because (1) I think it clutters up your main code path with error-handling logic, and (2) it forces you to always handle errors locally (even if that local code does not have the context to know how to handle the error) or return the error code through multiple layers of functions (back to where it can be handled).
That said, I completely agree that exceptions are also problematic. As you say, you can never really be sure of what exceptions can be thrown. Some languages have a "throw" keyword, in which you're meant to enumerate the list of possible exceptions; but of course, that's a headache to maintain, and is affected by inner code (such as library code) that might be completely out of your control or review. And when should the "throw" keyword be enforced, at compile time or runtime? And what should happen if the "throw" keyword's list of possible exceptions is violated?
Then of course there is the other problem with exceptions, the flip-side to being forced to handle an error locally: As your exception unwinds the stack, it might obliterate some local context that is needed to decide how to handle the error; or it might obliterate some local context that is needed to continue with your original task after the error has been handled!
The most interesting (and least broken) error-handling mechanism I've encountered is Common Lisp's "condition" system: http://www.gigamonkeys.com/book/beyond-exception-handling-co...
I see C++'s `std::set_new_handler` function [0] as C++'s less-capable equivalent to Lisp condition handlers. But the function invoked by `std::set_new_handler` lacks the ability to assess local context to decide how to handle the problem.
[0] http://www.cplusplus.com/reference/new/set_new_handler/
EDIT: I would love to see a language like Nim incorporate something like Lisp's condition system. Nim already offers "procedural types" (function pointers) [1] and closures [2] to capture variables from the enclosing scope. Nim even offers "anonymous procs" [3], to avoid the need to define new error-handling functions everywhere.
[1] https://nim-lang.org/docs/manual.html#types-procedural-type
[2] https://nim-lang.org/docs/manual.html#procedures-closures
[3] https://nim-lang.org/docs/manual.html#procedures-anonymous-p...
This is something that Nim offers via the `raises` pragma[1]. It is enforced at compile-time and in my experience works rather well.
1 - https://nim-lang.org/docs/manual.html#effect-system-exceptio...
[0] http://www.gigamonkeys.com/book/beyond-exception-handling-co...
Can we please let go of this meme? Many polyglot developers complain about the lack of generics, and how Go code ends up being more verbose and less expressive than languages like Python.
Things like interfaces and pointers to interfaces, structs vs slies and maps are not consistent.
Yeah, and inconsistencies are one of the things that make for a more complex language, not a simpler one. In fact, Go has generics, but they only work for magic, built-in types. I would argue that's less simple than just supporting generics, and building your standard library out of language features.
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
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.
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
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...
type FatalError error
func foo() FatalError {}