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

Post by bjackman » Wed, Jan 29, 2025, 9:34 AM UTC

pornel wrote: post #125

bjackman wrote: post #98

Earlier quoted context omitted.

But this just doesn't match my experience with Blaze at all. For my internal usage with C++ & Go it's perfect. For the weird niche use case of building and packaging BPF programs (with no support from the central tooling teams, we had to write our own macros) it still just works. For Python where it's a poor fit for the language norms it's a minor inconvenience but still mostly stays out of the way. I hear Java is si…

I count C++ projects in the "worst" bucket, where every project has its own build system, its own structure, own way to run tests, own way to configure features, own way to generate docs. So if a build system works great for your mixed C++ projects, your build system is taking on the maximum complexity to deal with it, and that's the complexity I don't want in non-C++ projects. When I work with pure-JS projects, or p…

Post by johnisgood » Wed, Jan 29, 2025, 11:31 AM UTC

Cthulhu_ wrote: post #152

indulona wrote: post #107

I wish Go Team would focus on performance rather thann adding new features that nobody asked for. The http stack is barely able to beat NodeJS these days, ffs.

The Go HTTP stack is not optimized for raw performance though; there's a number of alternative HTTP stacks written in Go optimized for performance, like fasthttp ( https://github.com/valyala/fasthttp ). (source: https://www.techempower.com/benchmarks/ ) Likewise, the standard library NodeJS http stack will not be as performant as a performance optimized alternative. That said, if raw performance is your primary conce…

Post by [deleted] » Wed, Jan 29, 2025, 12:21 PM UTC

pjmlp wrote: post #189

herval wrote: post #163

Earlier quoted context omitted.

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.

Post by jchw » Wed, Jan 29, 2025, 1:59 PM UTC

anttiharju wrote: post #186

jamietanna wrote: post #185

Earlier quoted context omitted.

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.

    go run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.63.4 run

Post by kbolino » Wed, Jan 29, 2025, 2:11 PM UTC

kbolino wrote: post #169

rednafi wrote: post #108

Earlier quoted context omitted.

Ah, thanks. This isn't much of an upgrade from the `tools.go` convention, where the tools are underscore-imported. All it does is provide an indication in the `go.mod` file that some dependencies come from tools. Plus, `go tool ` is slower than `./bin/ `. Not to mention, it doesn’t resolve the issue where tools might use a different version of a dependency than the app.

go tool is only slower when (re-)compilation is needed, which is not often. You'd have to pay the same price anyway at some point to build the binary placed in ./bin.