The State of Go

Spring might look bloat in the start, but it's powerful. At present there's no framework in golang which has so much power and freedom...

So let's special case `make()`, slices, channels, etc. so that some productivity is possible.

Then as they add library features they violate their own tenants as they find utility in these verboten constructs. Exceptions are bad...But we have panics which are in no way the same thing renamed. Never expose them outside a package...But closing an already closed channel panics. Random number generator functions panic on mundane and expected things, just like Java checked exceptions.

Example:

https://golang.org/pkg/math/rand/

``` func (Rand) Int31n

func (r Rand) Int31n(n int32) int32 Int31n returns, as an int32, a non-negative pseudo-random number in [0,n). It panics if n Standard behavior would be returning an error, not panicking,

See this:

https://blog.golang.org/defer-panic-and-recover

``` The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. ```

It's just an inconsistent and, quite frankly, disappointing language outside of goroutines and its interfaces. Those two make it possible to be productive, but with generics for instance a whole slew of new possibilities will emerge.

The simplicity is nice, but it's too simple and too inconsistent. All the verbosity of Java combined with the impenetrable inconsistency and abbreviations of C.

1) "if err != nil" after every statement

2) give some serious thought to whether the previous statement could panic or not

Good luck if it's a library call that may get updated or call other libraries !

3) Think about the non-error error cases that can't be abstracted out. Go is like C, in the sense that there is an ERETRY "error" (unsurprisingly, you should simply try again, you should NOT fail)

And there are cases where there can be an error and yet error is nil. Easy example of this would be sscanf.

And we now see practical Go code published online : how these problems are dealt with, real world edition:

1) either mindlessly putting "if err != nil { return err }", which is a very bad information-erasing exception system, or just outright ignoring errors. Don't you know you can also use "_" as the error variable ? Maybe they should make that implicit like in perl. Of course perl is likely to tell you this happened ... unlike C and Go.

(really brings back the C days doesn't it ?)

2) most people either don't know or just deny this. Thankfully panics at least do list where they occur. They also kill your program and print stacktraces. Pages and pages and pages of stacktraces.

3) very few people even know about these problems ... so they're ignored, and the standard Go tools themselves don't behave according to unix specifications.