And the same goes for Go. The only legitimate use of panic is still always-abort; recover merely helps one define what part of the program has aborted, and is a noop except within a deferred call — you'd be hard pressed to use recover as casually as exceptions in Java, Python or Ruby. Typically, this is the case when a master/workers scenario is implemented[0], where the master has to survive a worker's death, because they're different "processes", but the latter definitely dies from panicking (possibly even caused by a call to a third party lib such as described by kibwen)
The situation is actually a bit more nuanced in Go; an idiomatic Go library may use panic/recover internally as a means of error handling, but is supposed to convert any panics to error codes for external consumption (IOW, panics should not be a part of any public API). You can see this pattern endorsed in this blog post: https://blog.golang.org/defer-panic-and-recover .
[0]: https://github.com/urfave/negroni/blob/master/recovery.go#L1...