Well said!

It's not automatic though. You explicitly change your go.mod file and then it downloads the toolchains.

What i'd want is a way to revert back, if the user sees a problem.

The automatic updating toolchain is not a bad idea, and in most cases it works great. Once in a while though, there's a fuck up and breaks your build or something changes that you didnt expect.

The best way forward is to keep the old tool in a backup location, and have the user be able to revert the update with a single command. Then the user is able to safely return to the old one when the inevitable breakage happens. You could even opt-in to analytics for this action, and the owner of the tool would know if a particular update is a screwup (aka, many people reverted it).

To be clear, the new toolchain doesn't replace the old toolchain, but is installed alongside it, and is only used for modules that explicitly request the newer toolchain in their go.mod file.

Author here.

I think you misundertood how this feature works.

If you have a `go.mod` that sets a `go` directive with a version bigger than the version your Go toolchain is currently running, it will download the binary automatically and pass the commands to the new binary. However this doesn't replace your `go` binary in say, PATH, the new toolchain will be downloaded at `GOPATH`, the same as it does with your modules. This is why there is nothing to backup here, nothing is deleted.

Also, keep in mind that if Go is downloading a new toolchain, it means your project will not work with the current toolchain: because if you set `go 1.23` in your `go.mod`, and your current `go` is version 1.22, it would fail regardless until you either fix your `go.mod` or upgrade your `go` toolchain. What Go is doing here is the later, automatically for you.

If you didn't commit the breaking change to the repo, couldn't you just revert your local changes? Trashing the mod and sum file and running "tidy" should take care of the rest, I would think. Maybe I'm missing something?

I've done a few interviews like this recently. I always thought I was a OK programmer, judging from the feedbacks I get from colleagues. But after these interviews, I felt terrible. Doing my daily Leetcode as we speak...

I have an alternative solution to work with an existing struct that you can't change, e.g. protobuf generated code: https://jackieli.dev/posts/pointers-in-go-used-in-sql-scanne...

  type nullString struct {
    s *string
  }
  
  func (ts nullString) Scan(value interface{}) error {
    if value == nil {
        *ts.s = "" // nil to empty
        return nil
    }
    switch t := value.(type) {
    case string:
        *ts.s = t
    default:
        return fmt.Errorf("expect string in sql scan, got: %T", value)
    }
    return nil
  }
  
  func (n *nullString) Value() (driver.Value, error) {
    if n.s == nil {
        return "", nil
    }
    return *n.s, nil
  }

Then use it:

  var node struct { Name string }
  db.QueryRow("select name from node where id=?", id).Scan(nullString(&node.Name))

Nothing is perfect. I focus on solving problems

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa...

>According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (similar to how gRPC lives at "google.golang.org/grpc").

Random question, but how did they get the source code highlighting in that doc?

Code Blocks addong from G Suit Market (new doco -> addons -> Install -> Code Blocks)

Thinkpad in 3:2 for me

Same here. I can live without touch or stylus, just want a performance laptop with good screen (3:2 ratio) and keyboard.

Thinkpad?

Exactly! if only have have 3:2 screens!!! or better yet, a 4:3 screen!

Currently I'm buying a old X61s and going to convert it to X62: https://www.notebookcheck.net/Lenovo-X62-Laptop-Review.21159...

Is that ratio really so important? I have a wider ratio X1 Carbon and it has never bothered me, but I guess I wasn't used to anything in particular. The screen quality is really nice though.

Perhaps it's less evident especially if you have a multi-head setup with big monitors. But for almost every laptop now that uses display scaling to make screen content readable, screen estate is precious and the extra vertical space does make coding on a small screen much more enjoyable.

I just run away