rationales for go.lang's surprises

8.22: news.adda/go/assertions are no way to panic:
Why does Go not have assertions?

[ assertions allow you to say
crash if this condition doesn't hold true
because something is wrong
and the program will need debugging .]
. assertions are undeniably convenient
to avoid thinking about proper
error handling and reporting;
but, servers should not crash from non-fatal errors;
and, errors should be direct and to the point,
saving the programmer from interpreting a
large crash trace .
Precise errors are particularly important
when the programmer seeing the errors
is not familiar with the code.

no exceptions? well, panic is just as useful:

. func panic(interface{})
func recover() interface{} .
. these built-in functions assist in reporting and handling
run-time panics and program-defined error conditions.
. When a function F calls panic,
normal execution of F stops immediately.
Any functions whose execution was
deferred by the invocation of F
are run in the usual way,
and then F returns to its caller.
To the caller,
F then behaves like a call to panic,
terminating its own execution
and running deferred functions.
This continues until all functions in the goroutine
have ceased execution, in reverse order.
At that point, the program is terminated
and the error condition is reported,
including the value of the argument to panic.
This termination sequence is called panicking.
panic(42); panic("unreachable");
panic(Error("cannot parse")).
. The recover function allows a program to
manage behavior of a panicking goroutine.
Executing a recover call inside a deferred function
stops the panicking sequence by
restoring normal execution,
and retrieves the error value passed to the call of panic.
If recover is called outside the deferred function
it will not stop a panicking sequence.
In this case, or when the goroutine is not panicking,
recover returns nil.