News for hackers. Stuff that matters.

Sajmani

Re:Go 1.11 Beta 1 is released on Tuesday June 26, 2018 @11:16PM (#17405519)
The "go release" command is intended to support selecting the right version for a new package release. The golang.org/cmd/api command detects incompatible API changes and so can serve as the basis for an auto-bump feature.

I'd also like to see a command to generate a new major version as a wrapper of the previous major version (or vice versa), to simplify creating major versions that can coexist within the same program.

Re:Program your next server in Go on Tuesday June 07, 2016 @01:57PM (#11856282)
And these numbers are 5 years old :-)
Re:Go Concurrency Patterns: Context on Tuesday July 29, 2014 @01:57PM (#8103711)
Yes, we are working on static analysis and automated refactoring tools. We will make them available publicly when they are ready, but that won't be very soon. We wanted to publicize Context now to encourage people to start using it and incorporating it into new code and frameworks.
Re:Go Concurrency Patterns: Context on Tuesday July 29, 2014 @01:13PM (#8103381)
In Google, we use two approaches:

1) add an explicit Context parameter to each function that needs one; typically this is the first parameter and is named "ctx". This makes it obvious how to cancel that function and pass stuff through it, but it's a lot of work. We are developing static analysis and refactoring tools to help automate tasks like this.

2) use a package to map http.Requests to Contexts. This requires that whatever server handler you're using register a Context in a map for each http.Request and remove it when the request completes. You could do this using the gorilla context package, for example.

My personal preference is the explicit ctx parameter, since then libraries are agnostic to the framework being used. Different frameworks can provide their own Context implementations; middleware should not care.

Re:Go Concurrency Patterns: Pipelines and cancellation on Friday March 14, 2014 @07:09AM (#7397976)
Yes, interrupt is better, and the article explains how to do that a few paragraphs later:

        for n := range in {
            select {
            case out <- n * n:
            case <-done:
                return
            }
        }
If you allow pipeline stages to interrupt their receive loop instead of draining the inbound channel, then _all_ send operations need to be governed by done. Otherwise the interrupted receive loop may block the upstream sender.