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

31–40 of 207 posts

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

#31

Post by cirwin »

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 impact version selection for projects who use your module; those projects do not get `// indirect` lines in their go.mod because those packages are not required when building their module.

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

#32

Post by jeffbee »

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…

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.

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

#34

Post by sunshowers »

jeffbee wrote: post #32
sunshowers wrote: post #22

Earlier quoted context omitted.

(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…

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.

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

#35

Post by purpleidea »

go.mod and the golang tooling is a horror show. I absolutely LOVE the language, but dealing with the tooling is horrendous. I should blog about the specifics, but if you want a short version:

* not using posix args

* obscure incantations to run tests

* go.mod tooling is completely non-deterministic and hard to use, they should have just left the old-style vendor/ alone (which worked perfectly) and wrapped a git-submodules front-end on top for everyone who was afraid of submodules. Instead they reinvented this arcane new ecosystem.

If you want to rewrite the golang tooling, I'll consult on this for free.

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

#37

Post by [deleted] »

jamietanna wrote: post #19
lelandfe wrote: post #16

Earlier quoted context omitted.

Choosing colors is like making music. This color scheme feels discordant, like a jumble of loud notes. Maybe try looking at color palette creators online?

Thanks - this is based on the Srcery theme ( https://srcery.sh/ ) but maybe needs some tweaks, as per some suggestions in the thread

[deleted]

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

#38

Post by jlarsen »

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've had exactly the same thought, after hitting walls repeatedly with limitations in single-language ecosystems. And likewise, I've had the same concerns around the complexity that comes with Bazel/Buck/Nix.

It's been such a frustration for me that I started writing my own as a side project a year or two ago, based on a using a standardized filesystem structure for packages instead of a manifest or configuration language. By leaning into the filesystem heavily, you can avoid a lot of language lock-in and complexity that comes with other tools. And with fingerprint-based addressing for packages and files, it's quite fast. Incremental rebuild checks for my projects with hundreds of packages take only 200-300ms on my low-end laptop with an Intel N200 and mid-tier SSD.

It's an early stage project and the documentation needs some work, but if you're interested: https://github.com/somesocks/dryad https://somesocks.github.io/dryad/

One other alternative I know of that's multi-language is Pants(https://www.pantsbuild.org/), which has support for packages in several languages, and an "ad-hoc" mode which lets you build packages with a custom tool if it isn't officially supported. They've added support for quite a few new tools/languages lately, and seem to be very much an active project.

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

#39

Post by dprotaso »

Funny to see a little go library you wrote [1] show up in a blog post years later. I need to update it now that go has iterators and generics.

Another great blog post [2] covers performance issues with go tool

[1] https://github.com/dprotaso/go-yit

[2] https://blog.howardjohn.info/posts/go-tools-command/

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

#40

Post by syvolt »

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…

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 multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue?

Post reply on HN