> In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.
Well, there's no real way to recover after such an assert (the C stdlib is undefined when you catch the SIGABRT, the stack is not guaranteed to be big enough to do anything, most I/O is not guaranteed to work, etc. -- really, very few uses for catching a SIGABRT). There is a way in Go, even if it is far less capable than your average "except .." clause in C++.
> The reality is that Go does not have exceptions the way Python does.
True. Some of us (e.g. me) think that's a big advantage. (I'm not implying you disagree - I don't know what your opinion is)
I'm not a fan of the lack of exceptions in Go, but it's not a dealbreaker for me. I feel like Go code is very cluttered and fussy. I don't love the language as a language. But as a tool for getting systems programming problems solved, it is pretty amazing, and I love working with it.
Exactly (and probably for a reason)
> In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.
Well, there's no real way to recover after such an assert (the C stdlib is undefined when you catch the SIGABRT, the stack is not guaranteed to be big enough to do anything, most I/O is not guaranteed to work, etc. -- really, very few uses for catching a SIGABRT). There is a way in Go, even if it is far less capable than your average "except .." clause in C++.
> The reality is that Go does not have exceptions the way Python does.
True. Some of us (e.g. me) think that's a big advantage. (I'm not implying you disagree - I don't know what your opinion is)