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

41–50 of 207 posts

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

#41

Post by wakawaka28 »

syvolt wrote: post #40
cirwin wrote: post #31

Earlier quoted context omitted.

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…

>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.

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

#43

Post by munificent »

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 reinvention across ecosystems.

I don't necessarily think it's a bad thing. Yes, it's a lot of redundant work. But it's also an opportunity to shed historical baggage and learn from previous mistakes. Compare, for example, how beloved Rust's cargo ecosystem is compared the ongoing mess that is package management in Python.

A fresh start can be valuable, and not having a monoculture can be helpful for rapid evolution.

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

#44

Post by verdverm »

silverwind wrote: post #42
remram wrote: post #4

So it's just dev-dependencies?

Yes, except it does not support version ranges.

Go uses Minimum Version Selection (MVS) instead of a SAT solver. There are no ranges in any go dependency specifications. It's actually a very simple and elegant algorithm for dependency version selection

https://research.swtch.com/vgo-mvs

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

#45

Post by lihaoyi »

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…

My experience with Bazel is it does everything you need, and works incredibly well once set up, but is ferociously complex and hard to learn and get started with. Buck and Pants are easier in some ways, but fundamentally they still look and feel mostly like Bazel, warts and all

I've been working on an alternate build tool Mill (https://www.mill-build.org) tries to provide the 90% of Bazel that people need at 10% the complexity cost. From a greenfield perspective a lot of work to try and catch up to Bazel's cross-language support and community. I think we can eventually get there, but it will be a long slog

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

#46

Post by pornel »

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…

> Why do we need separate build systems for every language?

Because being cross-language makes them inherit all of the complexity of the worst languages they support.

The infinite flexibility required to accommodate everyone keeps costing you at every step.

You need to learn a tool that is more powerful than your language requires, and pay the cost of more abstraction layers than you need.

Then you have to work with snowflake projects that are all different in arbitrary ways, because the everything-agnostic tool didn't impose any conventions or constraints.

The vague do-it-all build systems make everything more complicated than necessary. Their "simple" components are either a mere execution primitive that make handling different platforms/versions/configurations your problem, or are macros/magic/plugins that are a fractal of a build system written inside a build system, with more custom complexity underneath.

OTOH a language-specific build system knows exactly what that language needs, and doesn't need to support more. It can include specific solutions and workarounds for its target environments, out of the box, because it knows what it's building and what platforms it supports. It can use conventions and defaults of its language to do most things without configuration. General build tools need build scripts written, debugged, and tweaked endlessly.

A single-language build tool can support just one standard project structure and have all projects and dependencies follow it. That makes it easier to work on other projects, and easier to write tooling that works with all of them. All because focused build system doesn't accommodate all the custom legacy projects of all languages.

You don't realize how much of a skill-and-effort black hole build scripts are is until you use a language where a build command just builds it.

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

#47

Post by verdverm »

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.

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

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

#48

Post by verdverm »

purpleidea wrote: post #35

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

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

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

#49

Post by arccy »

imiric wrote: post #10

This seems handy, but often the tools run by `go generate` are outside of the Go ecosystem, or need to be binaries. So I think a general solution would work better, and not be limited to Go. There are plenty of tools in this space to choose from: mise, devenv, Nix, Hermit, etc.

better motivation for rewrite it in go...

but are there really that many tools you need in a go project not written in go?

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

#50

Post by syvolt »

verdverm wrote: post #47
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.

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.
Post reply on HN