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

51–60 of 207 posts

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

#51

Post by syvolt »

wakawaka28 wrote: post #41
syvolt wrote: post #40

Earlier quoted context omitted.

Thank you for working on it. It is a nice feature and still better than alternatives. I'm not a library author and I try to be careful about what dependencies I introduce to my projects (including indirect dependencies). On one project, switching to `go tool` makes my go.mod go from 93 lines to 247 (excluding the tools themselves) - this makes it infeasible to manually review. If I'm only using a single feature of a…

>If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue? How is anyone supposed to know whether there's an issue or not? To simplify things, if you use the tool and the dependency belongs to the tool, then the issue can affect you. Anything more advanced than that requires analyzing the code.

What if I'm already using techniques, such as sandboxing, to prevent the tools from doing anything unexpected? Why bring this entire mess of indirect dependencies into my project if I'm just using a tool to occasionally analyze my binary's output size? Or a tool to lint my protobuf files?

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

#52

Post by verdverm »

syvolt wrote: post #50
verdverm wrote: post #47

Earlier quoted context omitted.

In addition, a good dependency security scanning tool can analyze reachability to answer this question for you

Reachability analysis on a tool that could be called by something outside of the project? We're talking about tools here after all - anything that can run `go tool` in that directory can call it. The go.mod tool entry could just be being used for versioning.

I'm speaking of tools and processes independent of this "go tool" stuff that we already use in our CI pipelines

Big fan of Dagger over this go tool thing

I generally loath the use of comments for things other than comments

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

#53

Post by marwis »

munificent wrote: post #43
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 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…

Sounds like the only way out of this is to design language agnostic tooling protocols that anybody can implement.

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

#54

Post by jrockway »

sunshowers wrote: post #34
jeffbee wrote: post #32

Earlier quoted context omitted.

This is likely because you are running it in some random PWD that doesn't represent a bazel workspace. When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time. Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.

That's good to know, thank you! Do you encounter cache invalidation bugs with daemonization often? I've had pretty bad experiences with daemonized dev tools in the past.

Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation.

If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.

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

#56

Post by pansa2 »

munificent wrote: post #43
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 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”.

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

#57

Post by jeffbee »

jrockway wrote: post #54
sunshowers wrote: post #34

Earlier quoted context omitted.

That's good to know, thank you! Do you encounter cache invalidation bugs with daemonization often? I've had pretty bad experiences with daemonized dev tools in the past.

Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation. If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.

I assumed they meant an error of improperly using cached results. I am sure bazel has its flaws but it assiduously avoids that.

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

#59

Post by wakawaka28 »

syvolt wrote: post #51
wakawaka28 wrote: post #41

Earlier quoted context omitted.

>If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue? How is anyone supposed to know whether there's an issue or not? To simplify things, if you use the tool and the dependency belongs to the tool, then the issue can affect you. Anything more advanced than that requires analyzing the code.

What if I'm already using techniques, such as sandboxing, to prevent the tools from doing anything unexpected? Why bring this entire mess of indirect dependencies into my project if I'm just using a tool to occasionally analyze my binary's output size? Or a tool to lint my protobuf files?

If it's a build dependency, then you have to have it. If you don't like the size of the tool then take it up with the authors. I'm not a Go programmer by the way, this is all just obvious to me.

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

#60

Post by caust1c »

cirwin wrote: post #31
syvolt wrote: post #3

I have tested it and probably will use it but the fact that it pollutes your go.mod's indirect dependency list (without any distinction indicating it's for a tool) is very annoying.

Primary contributor to the feature here. We went back on forth on this a lot , but it boiled down to wanting only one dependency graph per module instead of two. This simplifies things like security scanners, and other workflows that analyze your dependencies. A `// tool` comment would be a nice addition, it's probably not impossible to add, but the code is quite fiddly. Luckily for library authors, although it does…

Having not looked at it deeply yet, why require building every time it's invoked? Is the idea to get it working then add build caching later? Seems like a pretty big drawback (bigger than the go.mod pollution, for me). Github runners are sllooooow so build times matter to me.
Post reply on HN