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

181–190 of 207 posts

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

#181

Post by carlthome »

nixosbestos wrote: post #131
TheDong wrote: post #93

I think it's a bad addition since it pushes people towards a worse solution to a common problem. Using "go tool" forces you to have a bunch of dependencies in your go.mod that can conflict with your software's real dependency requirements, when there's zero reason those matter. You shouldn't have to care if one of your developer tools depends on a different version of a library than you. It makes it so the tools them…

I ask this out of curiosity, not accusation, do you work for Flox? Can't say I've ever seen it mentioned "in the wild".

Hehe, I was also wondering this.

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

#182

Post by [deleted] »

Thaxll wrote: post #151
LinXitoW wrote: post #137

Earlier quoted context omitted.

Go launched without any dependency management. Go people believe that anything non-trivial is either a useless abstraction, or too difficult for the average developer. So their solution is to simply not add it, and tell anyone claiming to need it that their mind has been poisoned by other languages... Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "gr…

go mod is best in class dependecy manager, it is way better than what most mainstream languages have, it's not even close. I worked with C++/ruby/python/js/java and C#, go mod is superior to all them. The one that is similar is Cargo ( rust ).

[deleted]

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

#184

Post by wakawaka28 »

verdverm wrote: post #161
wakawaka28 wrote: post #133

Earlier quoted context omitted.

That is a bit much to ask for IMO. In any case, the project may not be aware of how any given developer will use the tool. So who is to say that if you change the order of two parameters to the tool, the tool might not take a different path and proceed to hack your computer? You really don't want any of this problem. What you should ask for is for the tools' dependencies to be listed separately, and for each tool to…

> for each tool to ... "do one thing well." There is a lot of merit to this statement, as applied to `go tool` usage and to security scanning. Just went through a big security vendor analysis and POCs. In the middle I saw Filippo Valsorda post [1] about false positives from the one stop shops, while govulncheck (language specific) did not have them. At the same time, there was one vendor who did not false positive wi…

The similar/duplicated stuff can be rolled into libraries. Just don't make the libraries too big lol. I suspect there's less duplicated stuff than you think. Most of it would be stuff related to parsing files and command parameters, I guess.

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

#185

Post by jamietanna »

anttiharju wrote: post #177
arccy wrote: post #172

Earlier quoted context omitted.

i think it's more an argument to not use the dumpster fire that is golangci-lint

I've been working on a version manager for golangci-lint in the quiet moments [1] It already works, but it's work in progress. Happy to get feedback [1] https://github.com/anttiharju/vmatch

What's the use case you have over "just" using the official install process (`curl | sh`)?

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

#186

Post by anttiharju »

jamietanna wrote: post #185
anttiharju wrote: post #177

Earlier quoted context omitted.

I've been working on a version manager for golangci-lint in the quiet moments [1] It already works, but it's work in progress. Happy to get feedback [1] https://github.com/anttiharju/vmatch

What's the use case you have over "just" using the official install process (`curl | sh`)?

As long as a team agrees to have .golangci-version as the source of truth, the people using the tool don't have to worry about having the right version installed, as the wrapper fetches it on demand.

Having the wrong version installed between collaborators is problematic as then they may get different results and spend time wondering why.

Works across branches and projects.

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

#187

Post by pjmlp »

room271 wrote: post #145
LinXitoW wrote: post #137

Earlier quoted context omitted.

Go launched without any dependency management. Go people believe that anything non-trivial is either a useless abstraction, or too difficult for the average developer. So their solution is to simply not add it, and tell anyone claiming to need it that their mind has been poisoned by other languages... Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "gr…

Your reply is polemical and somewhat detached from the experience of working with Go. From my experience, Go's dependency management is far better than anything else I've worked with (across languages including Java, Scala, Javascript/Typescript, Python). Your criticism is perhaps relevant in relation to language features (though I would disagree with your position) but has no basis in relation to tooling and the sta…

I fail to see how working directly from code with direct url mappings to source code repositories is better than Maven, Graal, NuGET.

Anything is better than npm, with one function per package.

Python, thankfully I only need batteries for OS scripting.

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

#188

Post by pjmlp »

Thaxll wrote: post #151
LinXitoW wrote: post #137

Earlier quoted context omitted.

Go launched without any dependency management. Go people believe that anything non-trivial is either a useless abstraction, or too difficult for the average developer. So their solution is to simply not add it, and tell anyone claiming to need it that their mind has been poisoned by other languages... Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "gr…

go mod is best in class dependecy manager, it is way better than what most mainstream languages have, it's not even close. I worked with C++/ruby/python/js/java and C#, go mod is superior to all them. The one that is similar is Cargo ( rust ).

If all dependencies live in source code repos, and no one ever migrates their projects elsewhere, and placing URLs as imports directly on the source code, no thanks.

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

#189

Post by pjmlp »

herval wrote: post #163
potamic wrote: post #110

Earlier quoted context omitted.

Why do ecosystems continue to screw up dependency management in 2025? You would think the single most widely used feature by programmers everywhere would be a solved problem by now.

Go has been a masterclass in disparaging industry learnings as "unnecessary" (dep management, generics, null safety), then gradually bolting them into the language. It's kinda hilarious to watch.

It would be, if they didn't hit jackpot with Docker and Kubernetes adoption, and now many of us on DevOps space have to deal with it in some form.

A bit like C ignoring previous experience in safe systems, getting lucky with UNIX's adoption, and we are still trying to fix that to this day.

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

#190

Post by [deleted] »

larusso wrote: post #175
room271 wrote: post #171

Earlier quoted context omitted.

I have no beef with Rust, but objectively I think it's dependency management, general tooling, and standard library are significantly worse than Go's. The language, as you say, has a quite different philosophy from Go which many favour - but that is only part of the story. Could you elucidate which of the 'mentioned issues' you think are present for Go (in relation to tooling) that do not apply to Rust/cargo? Is your…

Each rust crate is compiled on their own. Means if a library you pull in, needs the same crate as a another dependency, even with incompatible versions, it doesn’t matter. Then cargo understands the difference between test and build dependencies next to the dependencies for the actual lib/binaries. The fact that each library and its dependencies gets compiled separately adds quite a lot in build time depending how ma…

[deleted]
Post reply on HN