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

Go 1.24's go tool is one of the best additions to the ecosystem in years

jvt.me

Post reply on HN
Print view View original

81–90 of 207 posts

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#81

Post by rob74 »

nikolayasdf123 wrote: post #66
Groxx wrote: post #65

Earlier quoted context omitted.

"Shared dependency state" was my very first thought when I heard about how it was built. Yeah I want none of that. I'll stick with my makefiles and a dedicated "internal/tools" module. Tools routinely force upgrades that break other things, and allowing that is a feature .

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

No one says that this is a one-size-fits-all solution, but for some use cases (small tools that are intimately connected to the rest of the codebase, even reuse some internal code/libraries) it's probably helpful...

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#82

Post by MathMonkeyMan »

nikolayasdf123 wrote: post #66
Groxx wrote: post #65

Earlier quoted context omitted.

"Shared dependency state" was my very first thought when I heard about how it was built. Yeah I want none of that. I'll stick with my makefiles and a dedicated "internal/tools" module. Tools routinely force upgrades that break other things, and allowing that is a feature .

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

The state of things with some projects I've touched is "We have a giant CI thing that does a bunch of things. It is really very large. It might or might not be broken, but we work around it and it's fine."

I think some of the euphoria around tracking tooling in the repo is "yes, now I can run a command in the repo and it's as if I spun up a docker container with the CI locally, but it's just regular software running on my machine!" This is a huge improvement if you're used to the minutes-or-hours-long CI cycle being your only interaction with the "real environment."

The reductio ad absurdum that you describe is basically "a snapshot of the definitions of all the container images in our CI pipeline." It's not a ridiculous example, it's how many large projects run.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#83

Post by Ferret7446 »

nikolayasdf123 wrote: post #66
Groxx wrote: post #65

Earlier quoted context omitted.

"Shared dependency state" was my very first thought when I heard about how it was built. Yeah I want none of that. I'll stick with my makefiles and a dedicated "internal/tools" module. Tools routinely force upgrades that break other things, and allowing that is a feature .

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

This take absolute boggles the mind. You don't want people compiling your code with different versions of tools so you have to debug thousands of potential combinations of everything. You don't want people running different versions of formatters/linters that leave conflicting diffs throughout your commit history.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#84

Post by spockz »

sunshowers wrote: post #22
bjackman wrote: post #20

I always think it's a shame that these features end up getting built into ecosystem-specific build tools. Why do we need separate build systems for every language? It seems entirely possible to have build system that can do all this stuff for every language at once. From my experience at Google I _know_ this is possible in a Megamonorepo. I have briefly fiddled with Bazel and it seems there's quite a barrier to entry…

(I worked on source control at FB for many years.) The main argument for not overly genericizing things is that you can deliver a better user experience through domain-specific code. For Bazel and buck2 specifically, they require a total commitment to it, which implies ongoing maintenance work. I also think the fact that they don't have open governance is a hindrance. Google's and Meta's internal monorepos make certa…

GraalVM’s native image has been a thing for a while now. This could overcome the daemon issue partially. The daemon does more ofc by as it keeps some state in memory. But at least the binary start time is a solved problem in Java land.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#85

Post by 9rx »

teeray wrote: post #5
guessmyname wrote: post #2

As someone who’s been using Go since 2013 at commpanies like Apple, Microsoft, and Uber, this all seems quite unnecessary. That said, if it helps people do “their thing” in what they believe is an easier (more straightforward) way, then I welcome the new changes.

Given Go’s approach to “metaprogramming” has long relied on tools written in Go, this does seem like a feature gap that needed closing. Even the introduction of `go generate` long ago formalized this approach, but still left installing the tools as an exercise for the reader. You can’t have consistent code gen if you don’t have consistent tooling across a team/CI.

> Even the introduction of `go generate` long ago formalized this approach

It did, but if you recall it came with a lot of "We have no idea why you need this" from Pike and friends. Which, of course, makes sense when you remember that they don't use the go toolchain inside Google. They use Google's toolchain, which already supports things like code generation and build dependency management in a far more elegant way. Had Go not transitioned to a community project, I expect we would have seen the same "We have no idea why you need this" from the Go project as that is another thing already handled by Google's tooling.

The parent's experience comes from similar sized companies as Google who have similar kinds of tooling as Google. His question comes not from a "why would you need this kind of feature?" in concept, but more of a "why would you not use the tooling you already have?" angle. And, to be fair, none of this is needed where you have better tooling, but the better tooling we know tends to require entire teams to maintain it, which is unrealistic for individuals to small organizations. So, this is a pretty good half-measure to allow the rest of us to play the same game in a smaller way.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#86

Post by nikolayasdf123 »

MathMonkeyMan wrote: post #82
nikolayasdf123 wrote: post #66

Earlier quoted context omitted.

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

The state of things with some projects I've touched is "We have a giant CI thing that does a bunch of things. It is really very large. It might or might not be broken, but we work around it and it's fine." I think some of the euphoria around tracking tooling in the repo is "yes, now I can run a command in the repo and it's as if I spun up a docker container with the CI locally, but it's just regular software running…

I am with you on the same boat that this better be versioned and reproducible and standardised.

my key concern whether tools to build project have to be in the same pool as project itself (that may or may not use tools to build/edit/maintain/debug it).

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#87

Post by nikolayasdf123 »

Ferret7446 wrote: post #83
nikolayasdf123 wrote: post #66

Earlier quoted context omitted.

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

This take absolute boggles the mind. You don't want people compiling your code with different versions of tools so you have to debug thousands of potential combinations of everything. You don't want people running different versions of formatters/linters that leave conflicting diffs throughout your commit history.

so where does it stop? let's include version of OS on laptop of people who edit code? it is getting ridiculous.

you got to draw a line somewhere.

in my opinion, "if dependency code is not linked nor compiled-into nor copied as a source (e.g. model weights, or other artefacts) then it must not be included into dependency tree of project source code"

that still means, you are free to track versions/hashes/etc. of tools and their dependencies. just do it separately.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#88

Post by SOLAR_FIELDS »

MathMonkeyMan wrote: post #82
nikolayasdf123 wrote: post #66

Earlier quoted context omitted.

same. tools are not part of the codebase, nor dependencies. you got to have isolation of artefact and tools around to work with it. it is bonkers to start versioning tools used to build project mixed with artefact dependencies itself. should we include version of VSCode used to type code? how about transitive dependencies of VSCode? how about OS itself to edit files? how about version of LLM model that generated some…

The state of things with some projects I've touched is "We have a giant CI thing that does a bunch of things. It is really very large. It might or might not be broken, but we work around it and it's fine." I think some of the euphoria around tracking tooling in the repo is "yes, now I can run a command in the repo and it's as if I spun up a docker container with the CI locally, but it's just regular software running…

It makes sense to some extent when the toolchain can tap into native language specific constructs when you need that REPL-like iteration loop to be tight and fast. But that kind of thing is probably only required in a small subset of the kind of tooling that gets implemented.

The tradeoff with this approach is that you lose any sort of agnosticism when you drop into the language specific tooling. So now if you work at a corporation and have to deal with multiple toolchains every engineer now needs to learn and work with new build tooling X times for each supported language. This always happens to some extent - there’s always going to be some things that use the language’s specific task runner constructs - but keeping that minimal is usually a good idea in this scenario.

Your complaint feels to me that it is about poorly implemented CI systems that heavily leverage container based workflows (of which there are many in the wild). If implemented properly with caching, really the main overhead you are paying in these types of setups is the virtualization overhead (on macs) and the cold start time for the engine. For most people and in most cases neither will make a significant difference in the wall clock time of their loop, comparatively.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#89

Post by verdverm »

purpleidea wrote: post #70
verdverm wrote: post #48

Earlier quoted context omitted.

MVS, the algo for dep version selection, is deterministic, given the same inputs you will get the same outputs. Go has invested a lot of effort in creating reproducible builds through the entire toolchain https://research.swtch.com/vgo-mvs

The _tooling_ is not reproducible. Take a not small golang project with some number of dependencies and there should be a single list of the latest versions for the entire project. And exactly what golang commands do you run to generate that list? It's totally broken. This is why so many tools cropped up like go-mod-upgrade and so on. Everyone downvoting obviously doesn't understand the problem.

`go.mod` contains the dependency list and minimum version required

`go.sum` is a lock file for the exact versions to use (ensures reproducibility)

`go mod graph` will produce the dependency graph with resolved versions

`go list -deps ./...` will give you all packages used by a module or directory, depending on the args you provide

`go get -u ./...` will update all dependencies to their latest version

Here is a post about Go toolchain reproducibility and verification: https://go.dev/blog/rebuild

You are being downvoted for being wrong and talking about downvoting, which is called out as something not to do in the posting & commenting guidelines

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#90

Post by makapuf »

pansa2 wrote: post #56
munificent wrote: post #43

Earlier quoted context omitted.

I think the problem is basically because the build system has to be implemented using some ecosystem, and no other ecosystem wants to depend on that one. If your "one build system to rule them all" was built in, say, Ruby, the Python ecosystem won't want to use it. No Python evangelist wants to tell users that step 1 of getting up and running with Python is "Install Ruby". So you tend to get a lot of wheel reinventio…

> No Python evangelist wants to tell users that step 1 of getting up and running with Python is "Install Ruby". True, but the Python community does seem to be coalescing around tools like UV and Ruff, written in Rust. Presumably that’s more acceptable because it’s a compiled language, so they tell users to “install UV” not “install Rust”.

Note that installing python stdlib installs tkinter and thus tcl.

https://wiki.tcl-lang.org/page/Python-Tcl-Interactions

Post reply on HN