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

61–70 of 207 posts

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

#61

Post by 6keZbCECT2uB »

sunshowers wrote: post #25
6keZbCECT2uB wrote: post #24

Earlier quoted context omitted.

I agree. In my opinion, if you can keep the experience of Bazel limited to build targets, there is a low barrier to entry even if it is tedious. Major issues show up with Bazel once you start having to write rules, tool chains, or if your workspace file talks to the Internet. I think you can fix these issues by using a package manager around Bazel. Conda is my preferred choice because it is in the top tier for adopti…

> You really don't want to have to deal with multiple versions of the same library with compiled languages, but you have to with JavaScript. Rust handles this fine by unifying up to semver compatibility -- diamond dependency hell is an artifact of the lack of namespacing in many older languages.

Conda unifies by using a sat solver to find versions of software which are mutually compatible regardless of whether they agree on the meaning of semver. So, both approaches require unifying versions. Linking against C gets pretty broken without this.

The issue I was referring to is that in Javascript, you can write code which uses multiple versions of the same library which are mutually incompatible. Since they're mutually incompatible, no sat-solve or unifyer is going to help you. You must permit multiple versions of the same library in the same environment. So far, my approach of ignoring some Javascript libraries has worked for my backend development. :)

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

#62

Post by syvolt »

wakawaka28 wrote: post #59
syvolt wrote: post #51

Earlier quoted context omitted.

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.

The functionality we're discussing can be used for tools that are not build dependencies. They may be important for your project and worth having contributors be on the same version but not part of the build.

It will still add the dependencies of those tools as indirect dependencies to your go.mod file, that is what's being discussed.

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

#63

Post by 6keZbCECT2uB »

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…

Partly in jest, you can often find a Perl / bash available where you can't find a Python, Ruby, or Cargo.

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

#65

Post by Groxx »

amukher1 wrote: post #55

Found this a lot easier to follow. https://blog.howardjohn.info/posts/go-tools-command/ And didn't quite understand the euphoria.

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

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

#66

Post by nikolayasdf123 »

Groxx wrote: post #65
amukher1 wrote: post #55

Found this a lot easier to follow. https://blog.howardjohn.info/posts/go-tools-command/ And didn't quite understand the euphoria.

"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 of this code? where does this stop?

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

#68

Post by __float »

jeffbee wrote: post #57
jrockway wrote: post #54

Earlier quoted context omitted.

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.

Yes, unless you're using persistent workers. Then you may very well run into the same issues they mention.

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

#69

Post by cirwin »

caust1c wrote: post #60
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…

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.

`go tool` doesn't require a rebuild, but it does checking that the tool is up-to-date (which requires doing at least a bit of work).

This is one of the main advantages of using `go tool` over the "hope that contributors to have the right version installed" approach. As the version of the tool required by the project evolves, it continues to work.

Interestingly, when I was first working on the proposal, `go run` deliberately did not cache the built binary. That meant that `go tool` was much faster because it only had to do the check instead of re-running the `link` step. In Go 1.24 that was changed (both to support `go tool`, but also for some other work they are planning) so this advantage of `go tool` is not needed anymore.

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

#70

Post by purpleidea »

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

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.

Post reply on HN