Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Context should go away for Go 2 (2017)

faiface.github.io

Post reply on HN
Print view View original

1–10 of 176 posts

Re: Context should go away for Go 2 (2017)

#4

Post by mrkeen »

> If the Go language ever comes to the point where I’d have to write this

  n, err := r.Read(context.TODO(), p)
> put a bullet in my head, please.

Manually passing around a context everywhere sounds about as palatable as manually checking every return for error.

Re: Context should go away for Go 2 (2017)

#5

Post by the_gipsy »

> This probably doesn’t happen often, but it’s prone to name collisions.

It's funny, it really was just using strings as keys until quite recently, and obviously there were collisions and there was no way to "protect" a key/value, etc.

Now the convention is to use a key with a private type, so no more collisions. The value you get is still untyped and needs to be cast, though. Also there are still many older libraries still uses strings.

Re: Context should go away for Go 2 (2017)

#6

Post by pluto_modadic »

new solution should be: Simple and elegant. Optional, non-intrusive and non-infectious. Robust and efficient. Only solves the cancelation problem.

okay... so they dodged the thing I thought was going to be interesting, how would you solve passing state? e.g. if I write a middleware for net/http, I have to duplicate the entire http.Request, and add my value to it.

Re: Context should go away for Go 2 (2017)

#7

Post by the_gipsy »

mrkeen wrote: post #4

> If the Go language ever comes to the point where I’d have to write this n, err := r.Read(context.TODO(), p) > put a bullet in my head, please. Manually passing around a context everywhere sounds about as palatable as manually checking every return for error.

Exactly, the snippets needs at least three lines of inane error checking boilerplate and variable juggling.

Re: Context should go away for Go 2 (2017)

#8

Post by mukunda_johnson »

> It’s very similar to thread-local storage. We know how bad of an idea thread-local storage is. Non-flexible, complicates usage, composition, testing.

I kind of do wish we had goroutine local storage though :) Passing down the context of the request everywhere is ugly.

Re: Context should go away for Go 2 (2017)

#10

Post by bheadmaster »

Contexts in Go are generally used for convenience in request cancellation, but they're not required, and they're not the only way to do it. Under the hood, a context is just a channel that's closed on cancellation. The way it was done before contexts was pretty much the same:

    func CancellableOp(done chan error /* , args... */) {
        for {
            // ...

            // cancellable code:
            select {
                case
Some compare context "virus" to async virus in languages that bolt-on async runtime on top of sync syntax - but the main difference is you can compose context-aware code with context-oblivious code (by passing context.Background()), and vice versa with no problems. E.g. here's a context-aware wrapper for the standard `io.Reader` that is completely compatible with `io.Reader`:

    type ioContextReader struct {
        io.Reader
        ctx context.Context
    }

    func (rc ioContextReader) Read(p []byte) (n int, err error) {
        done := make(chan struct{})
        go func() {
            n, err = rc.Reader.Read(p)
            close(done)
        }()

        select {
        case
For io.ReadCloser, we could call `Close()` method when context exits, or even better, with `context.AfterFunc(ctx, rc.Close)`.

Contexts definitely have flaws - verbosity being the one I hate the most - but having them behave as ordinary values, just like errors, makes context-aware code more understandable and flexible.

And just like errors, having cancellation done automatically makes code more prone to errors. When you don't put "on-cancel" code, your code gets cancelled but doesn't clean up after itself. When you don't select on `ctx.Done()` your code doesn't get cancelled at all, making the bug more obvious.

Post reply on HN