I think it's a wash. Go programs emit "fatal error: success" less than C programs, which is nice. An exception is fine if it has the information you need to debug the problem, but the names of the functions along the way aren't enough on their own. Consider: "program failed: Get "https://does-not-exist.invalid/": dial tcp: lookup does-not-exist.invalid on 8.8.8.8:53: no such host" vs. "IOException: no such host" and then a bunch of stack frames that don't tell you someone put "does-not-exist.invalid" in the config file. (Usually the operator won't type that, they'll type correct-hostnmae.internal instead of correct-hostname.internal, in a config file with 100 other non-one-letter-typo'd hostnames ;)
The way I see it, Proper error logging > Stack traces >> No stack traces. Proper error logging requires effort whatever you do. In some languages, even if you don't put in any effort, you still get stack traces (most exception-based languages), in others you get almost no context (C++, Go, Haskell etc).
If your team is spending time on good error messages, then it doesn't matter as much what language-level error support there is. If this time isn't being spent, I think you'll have a much nicer debugging experience in a system which at least collects stack traces.
Even for your example, let's say the stack trace is:
NoSuchHostException in stdlib.LookupHost() line 341
called from stdlib.HttpGet() line 6131
called from applicationLogic.DoSomething() line 123
called from main.main() line 3
In Go, with similar effort spent on error reporting along the way (if err != nil { return nil, err } vs automatic exception propagation) you'd find
Failed to do something: "no such host"
I think there's a much better chance to figure out what happened in the first case.
