1. 32
  1.  

  2. 21

    This looks like a pretty incredible quality of life release. I’m super excited by a ton of the changes, but I’ll outline a few below:

    • Build commands like go build and go test no longer modify go.mod and go.sum by default, go install now accepts arguments with version suffixes - these seemed like pretty big oversights and they fix a number of hacks I’ve had to put in place for my dockerfiles.
    • https://tip.golang.org/pkg/embed/ - this allows for simple bundling of assets, templates, etc, all built-in to the language now. You previously had to use 3rd party packages for this.
    • The new runtime/metrics package introduces a stable interface for reading implementation-defined metrics from the Go runtime - this will be nice for implementing your own metrics as well and I’m assuming a solution will pop up to allow these to be exported, similar to /debug/vars
    • The new io/fs package defines an abstraction for read-only trees of files - another exciting feature that’s been missing for a long time. The main alternative for this is billy which as far as I know is almost entirely used by go-git.
    • The new Func function allows registering a flag implemented by calling a function, as a lighter-weight alternative to implementing the Value interface.
    • The new NotifyContext function allows creating contexts that are canceled upon arrival of specific signals.
    • A new CommentNode was added to the parse tree. The Mode field in the parse.Tree enables access to it. - this should make it easier to write interesting documentation tools

    I’ve been holding off on some of my side projects because I was waiting for embed (and because I’ve got so much else on my plate), so maybe it’s time to dust those off.

    1. 1

      Go summary, especially calling out embedding. I had missed that!

    2. 4

      That “embed” package looks fun!

      1. 1

        What is fun about it?

        1. 15

          It replaces a whole slew of other packages which do pretty much the same thing.

          In particular, I’m excited about being able to just embed all the assets for a web-app into the binary. Then you can just distribute the binary and have it serve the assets as if it were from an actual FS.

          I’m assuming people will end up writing adapters which will allow you to use assets on the FS in dev and the bundled assets in prod. This was hard in the past because there were so many alternatives.

          1. 2

            I would rather shipping the static assets as a separate layer inside my container rather than bundling it into the binary. But there are use cases outside of containers that perhaps static assets would be nice to have. I.e. desktop ui app

            1. 3

              Not everything runs in a container; not even web apps.

            2. 1

              Considering how the Go toolkit has evolved, I imagine (and hope) it will be a native feature of the Go build/test tools such that you won’t need adapters. It’ll simply be a build flag/annotation