|
|
|
|
|
|
by lobster_johnson
4223 days ago
|
|
|
For the record, I don't think the interface problem is "mindblowingly wrong idiocy" (you words!). But I think it's a good indicator of how parts of Go's design are flawed from the outset. Design is hard to change later, so it's important to get it right from the start. Again, I totally buy explicit error propagation. I just think Go's solution ends up cluttering your code. It's so focused on errors, yet handling isn't a first-class construct, and the mechanisms it gives you for dealing with errors aren't very good. You have the cast check (a, ok := ...) and you can do a type switch (switch a := err.(type) { ... }), but it's rather weak for something that permeates every corner of the language. At least us have pattern matching. I find the stack frame problem disappointing. It's amazing that there are now several libraries to create artificial stack frames (eg., https://github.com/facebookgo/stack) just so you get this. |
|
|
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.