They certainly do propagate across API surfaces. People just ignore that.

Just like Go error handling : looking on github you see that Go mostly makes it easy and less visible if people totally ignore errors.

Go's exceptions are called panics; the recommended practice is generally not to let them cross API surfaces, and the standard library (again, generally) follows that.

It is, of course, possible to create libraries that don't follow the idiom.

> It is, of course, possible to create libraries that don't follow the idiom.

Yeah. Thing is though, there are these libraries who access pointers (especially in Go where lots of stuff are implicit pointers, like maps and interfaces). Or, may God strike them down where they stand, people who use division. Or allocate. Or cast. Or use interface{}. All such code has implicit (non-visible) panics in them.

What I mean to say is: in practice, Go code is not fundamentally different from Java/C++ code : everything can throw. Everything. Yes even that thing that you're thinking of right now that couldn't possibly ever think about throwing. There's just people who admit this and people who don't.

That the Go authors come up with idioms that are so incredibly shortsighted is emblematic of everything else about the language.

This is how Go works. They claim they are perfection, and know better than anyone.

For instance, compare:

https://blog.golang.org/go15gc

with

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

(just to put up something other than the generics discussion. But everything about go suffers from both massive deficiencies and an extremely arrogant development defending deficiencies ...)