> About your first point : yes, go has exceptions, the so-called panics, but they are here for truly exceptional situations, those you can't recover for, 1) I

> About your first point : yes, go has exceptions, the so-called panics, but they are here for truly exceptional situations, those you can't recover for, 1) I recover from such errors in Java all the time. It's easy : execute finally's ("defers"), execute retry policy (go, incidentally, makes generic retry policies very fucking hard due to lack of generics. It is impossible to write a method "TryThreeTimes(method, timeout, params)" in Go. 2) It is extremely disappointing that after all the effort that Go forces on you for error handling there are still a dozen classes of errors (of the kind you find often) that can kill your program, even with error handling perfectly up to the Golang author's standards. 3) These errors happen often enough that it's not reasonable to kill the program if they happen, so you absolutely need to recover in daemons and the like. So any reasonably large Go program has to consider exception handling, recovery, and alternate method returns. 4) You also have the C++ problem : libraries should never, ever raise an exception ("panic"). But of course, they do (ok granted, the Go standard library is reasonably good about this, but the same cannot be said for github stuff) 5) Nobody actually does the error handling. You never see anything other than "return err" or "exit program with log message" in error branches anyway) > I really think (and it looks like we strongly disagree on this point) it's one of Go's virtues to really distinguish between what's part of the problem you're trying to solve Yeah we disagree here. I feel Go's error handling standard prevents me from focusing on the problem independently of what might go wrong, and this limits my abstract thinking. What makes this even more frustrating is that this is exactly the same problem C had. > This is clearly not the way I work but that's a serious fault from developers if they do. With the guarantee of quality developers, I'd develop nearly anything in C++. There is no problem in C++ if you have a really good team and there's just no beating the C++ language in too many departments (portability, abstraction, compiler quality, tooling, power, control of complexity in huge programs ...). But the great failing of C++ is simple : it doesn't support junior programmers, or otherwise somewhat incompetent teams very well at all. The question here is : does Go ? I don't know, but to me it's not looking good. I would argue that the damage that can be done by slightly incompetent programmers in Go far exceeds the damage that can be done in most other languages (ok, granted, maybe it's better than C++, but definitely worse than Java).