Thanks for the feedback.
Please do add these notes to the wikis as discussed at
https://go.googlesource.com/proposal/+/master/design/go2draft.md .
Thanks.
Ian
On Wed, Oct 17, 2018 at 3:13 PM, Aditya Mukerjee <d...@chimeracoder.net> wrote:
> Recently, several developers at Stripe 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)
>
> 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.
--
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.
