This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality.
It is a go convention that library code doesn't let panics escape to the calling code, so if you are going to use panics in your own code, to follow the convention you should be recovering from them somewhere in the call chain that you control rather than letting them escape across the public API of your code. But that's it, they exist, and can be used. So, while there may be some ground to complain that when calling the standard library you have to handle error returns rather than catching exceptions (equivalently, "recovering from panics") -- though, IMO, there is a good reason for this design choice -- there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation -- to say that you don't have exceptions that you can use within your own code and that you have to to error-return handling at every level in your own code to deal with error propagation. If you make that complaint, it is clear you don't know what you are talking about.