At my last job, very few methods in the application ended up throwing a specific list of exceptions, except the most leaf-ward modules. Anything anywhere near the application logic just threw our top level generic exception, because there was too much below them that could throw a variety of exceptions, and there generally was nothing the middle-tier code could do about it if they failed.
It's really not that easy to ignore errors in Go in practice... and you might as well worry that a library correctly handles the result of string.Split() incorrectly. Either one is a bug. Hopefully your tests would find either one, and there are tools to detect errors you didn't handle.
You don't do that in API-stable code, period. If you are working with API-unstable code - that's the point of static typing. The code won't compile because the intention is exactly to signal that something has changed.
If you change the return type of a low-level Go function, you will have to modify its callers as well.
Anything anywhere near the application logic just threw our top level generic exception,
Bad codebase = bad. Sure. I never encountered that problem in the Java codebases I worked on at various employers. (And I'd be quite happy to complain about Java, I don't like it.)
It's really not that easy to ignore errors in Go in practice...
It is. The compiler will not emit a warning when you ignore the return value of a function/method. Here:
fmt.Println("Hello world")
Of course, if you have checked exceptions (which are for some unfathomable reason considered bad nowadays), nothing just throws an exception. Moreover, you don't know for sure whether a Go library correctly handles errors, because it's so easy to ignore them.