I work at Microsoft and I'd use Java (not even C# and yes at work) a hundred times before I'd consider using Go again. Go dependency management is a bit better these days, but the build system is an absolute mess, logging is dreadful, and IDE support seems pretty primitive. Also, Exceptions are vastly superior for most services compared to returning an error outside of a few edge cases since most of the time I have no idea how to handle errors at the callsite and really just need to handle any errors at a high level (like reverting the transaction and returning an HTTP error code).
I love how these people think I have a choice in languages to use, or that I haven’t tried several others as well and honestly don’t mind the idea of Java. My company wants to make money don’t cutting edge algorithms, not test out Google’s language du jour.
> I love how these people think I have a choice in languages to use
Probably because you wrote, "At my workplace, we’re thinking about using it" and not "my workplace is demanding we use it"
> or that I haven’t tried several others
(I'm not the person who replied and suggested Go, but your comment does make it sound like you are in the language-evaluation phase, not the "we're fully committed to Java after reviewing multiple options" phase)
My friend, I specifically asked for good Java resources, but did not ask for other opinions. Those who suggested other languages were just cutting in to the conversation. I don’t care about their reasoning, I just wanted to learn Java.
I love how these people think I have a choice in languages to use, or that I haven’t tried several others as well and honestly don’t mind the idea of Java. My company wants to make money don’t cutting edge algorithms, not test out Google’s language du an.
Go has exceptions, with the usual stack unwinding. The standard library does not use them (for the most part, panics are sometimes used to simplify error handling code, see encoding/gob). It's like Perl and Rust in this regard. Undocumented exceptions/panics are often considered security vulnerabilities by the Go team.
The argument against exceptions is that non-local control flow can introduce obscure bugs, like forgetting to clean up resources on the (invisible) exceptional execution path. On the other hand, without exceptions, it's possible to end up with no error handling at all by accident, and that too is not visible in the source code (but linters can help, of course).
Many languages which are anti-exception as a matter of principle still use them to report out-of-memory conditions, out-of-bounds array indices, integer division by zero, or attempts to access absent optional values. Not doing this results in code that is simply too verbose.
> like forgetting to clean up resources on the (invisible) exceptional execution path
Except this is still possible on the non-exceptional execution path. You simply just need to forget the defer call. The only thing that solves this is RAII and destructors.
