3 ms·

> Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). Th

> Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. > For another, I would want to make sure I had tooling that could tell me "is this library in use by service X". I don't know Go's story there, but I would hope it's trivial to do so for a library but I suspect if it's part of the standard library that may be trickier. If not, nbd. This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for.

staticassertion 5y ago
> This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. The issue isn't with installing the new compiler, that's trivial in our use case as well (for Rust at least, Python's a disaster, but I accept that). The issue is ensuring compatibility, ensuring no new bugs are introduced, etc. It's just a much heavier change to your produced binary vs changing a package. > This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for. Cool, thanks.