Recently, several developers at Stripe <https://stripe.com/> who write Go
regularly for their work met to discuss the Go 2 design drafts for error
handling, error values, and generics. The goal of the meeting was *not*
necessarily
to provide a single conclusion on each of the design drafts, but rather to
collect perspectives and opinions from various Go developers at Stripe to
share more broadly. I took notes notes on the discussion; the raw and
unfiltered notes are below, and I've put a short summary at the top.
As a preface:
* About ten people were present
* Not all Go developers at Stripe were present; this was a group of people
who are particularly passionate about Go (and happened to be available)
* I attempted to take direct quotations as much as possible (even if the
comments were blunt at times)
These notes do not reflect my personal opinions on the design drafts; they
are a compilation of different perspectives that other people shared during
the meeting, and which I am relaying. However, if you have questions about
any of the points that people raised, I'm happy to elaborate to the best of
my memory.
*Overview*
*People were happy to see that check/handle was not a Java-like exception
construct, which brings too much baggage from other languages. However,
they found the control flow to be confusion, and were skeptical of whether
there were enough workflows that benefited from the change to justify the
added complexity. There was one workflow which was a notable exception: the
check/handle construct would facilitate the pattern of “if there is any
error of a certain type, perform cleanup actions”.Error values were
generally received positively, with the main questions being around how
this would intersect with pkg/errors. There were a number of fans of
pkg/errors (one person said “pkg/errors solved contextual information in
error handling for me”). Since the error values draft is philosophically
similar to pkg/errors, this was generally a positive piece of feedback,
aside from questions about how a migration would work.*
*The design draft on generics generated the most confusion and the sharpest
feedback. People were overall happy with the goal of being able to use
complex data structures that others write, instead of reimplementing them
ourselves. However, they were not sold on the use of contracts to achieve
that goal. The syntax was controversial, and so were the semantics: people
pointed out that it was confusing to reason about the implications of even
seemingly-simple contracts (such as the Apply) example.*
*Raw notes*
*Error Handling: - How does the control flow look?- “Took me a while to get
it, but it seems kind of reasonable. But it’s pretty hard to explain up
front”- “I’m concerned that it’s hard to figure out - it’s no longer ‘going
forward’ through the function, but now jumping around in strange ways”-
“One tenet of Go has always been its readability, and you could always read
top to bottom within a package. The fact that you jump around between
handle blocks until one of them happens to return is strange”- “The
canonical example in the design draft - even that one you have to read a
few times to realize that it goes from a lower-defined handle block up to a
previously-defined one”- “What happens if none of the handle blocks return?
It’s not clear to me”- “Inner to outer, then up, then back”- “It’s about as
difficult to explain as defer, but the intersection of both is weird”- “In
small functions, it probably would scan better to have the if-check, rather
than the check-handle”- “It is designed to remove boilerplate, but it
introduces complexity. This was not originally something I found painful to
deal with in the language. It feels like a solution without a problem”-
“Now my snippet for expanding if err != nil will have to expand to “handle
err { return err }”, but otherwise it won’t add anything for me”- “Is
`defer check f.Close()` valid? If so, this would make a huge help for us in
<name of service>”- “If any error of a certain type, clean everything up” -
this makes that easier” (example code:
https://gist.github.com/ChimeraCoder/9fdef30e84ab374b612533ae4fd06873
<https://gist.github.com/ChimeraCoder/9fdef30e84ab374b612533ae4fd06873>)-
For error handling: I really like the `check` nomenclature, rather than the
other suggestion of `try`. As a recovering Java programmer, I feel like
`try` brings in too much baggage from that language family, and leads folks
to start "thinking in exceptions" rather than adapting to Go's error
handling concepts.Error values: - “This sounds like the `failure` library
in Rust [which may be a good thing, but is definitely an improvement over
the status quo”- Look at the new errors proposal for Rust, which is
considering putting the entire stacktrace on the error itself (controlled
by an environment variable)- “pkg/errors solved contextual information in
error handling for me”- What happens if you wrap a lot of errors with
`fmt.Errorf`?Generics: - “I’m +1 on having complicated data structures
implemented by others so I don’t have to, but I’m not sure about the
contract syntax”- “If I created a contract that essentially is powerful
enough to say ‘this type must be higher-kinded’, how does the compiler know
that that contract is undecidable?”- “This reeks of the situation with the
alias proposals, where as soon as it was released into the wild, people
discovered ways to write nonsensical aliases with it, and that’s why the
final version took out the values portion (leaving only type aliases)”-
“This feels half-baked”- “I’m even a Lisper, but why do we want everything
to be in more parenthesized groups?”- “I’m in favor of stronger type
systems, and Go’s type system is not particularly sound as it is. But I’m
not sure contracts meaningfully moves the needle in one direction or the
other in terms of making things better or worse vs. keeping things the
same”- “The Apply() example is awkward syntax, and also really
non-obvious”:
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md*
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
