And nearly anything you can call in any language could theoretically exit(3). The difference is that exceptions are a normal control structure in C#, Java, or even C++, while the use of panic should be exceptional. It's not considered the regular way to report an error.

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.

The problem with checked exceptions is that your code trends towards having every method marked as 'throws Exception' (or whatever your application's top level exception is). Any time a low level method changes to throw a new exception, every method that calls it has to update their exception spec... or they need to have their catch clauses updated to catch the additional exception and either deal with it - unlikely - or wrap it and rethrow it as one of their other expected exceptions.... or they're already catching Exception, which is also bad.

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.

Any time a low level method changes to throw a new exception,

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")

I have just ignored an error. The compiler is happy. There are quite some Go packages in the wild that do not deal with errors when they need to.

Panics are very rare in go code, particularly in libraries, they are not used for error control but for truly exceptional situations.

As others have said, it is highly discouraged by the community to use panics as control flow. Generally a panic means there's a serious bug somewhere - not just that unexpected stuff happened, but the programmer actively is doing something wrong.

Any library that panics for reasons other than a programmer bug would never be used by the community. I read a lot of Go code and look at a lot of Go libraries, and I've never seen one that said it purposely panics in my 3.5 years of writing Go.

Compared to Java, C#, Python, C++ etc... where declaring your code panics is a perfectly normal and expected way to report errors.

the most obvious difference is a go-panic and exceptions are used in different scenarios.

it's considered bad practice in go library code to panic(), while it is considered normal error handling to throw an exception in java.

also note that you can catch a panic in go, and use it as some kind of exceptions if you really must.

https://github.com/golang/go/wiki/PanicAndRecover#usage-in-a...