top | item 8631769

(no title)

joelgwebber | 11 years ago

I don't want to pick nits too much here, but "[...] leading to the whole non-nil value being nil idiocy; it's mindblowing that they got this so wrong." So I paraphrased a bit :)

I understand that some may find the error handling a bit too verbose, but humbly submit that there's a legitimate tradeoff to be made in terms of language complexity vs. verbosity, and the Go team generally tends to fall on the side of simplicity over tersity. This works well for us, but not everyone will find it palatable. YMMV and all that.

The stack frame "problem" doesn't seem all that bad to me. It would be nice to have a built-in solution, but our own code for dealing with this is one tiny file someone banged out in a couple of hours, so I'd hardly call it more than a stumbling block. After watching the Java world deal indefinitely with untold design flaws in core libraries, I support keeping things simple at the outset wherever possible.

But hey, there are lots of choices out there, so I'm not telling anyone they must write their servers in Go. Just that it works well for us.

discuss

order

No comments yet.