[HN Gopher] Go 1.24's go tool is one of the best additions to th...
___________________________________________________________________
Go 1.24's go tool is one of the best additions to the ecosystem in
years
Author : keybits
Score : 93 points
Date : 2025-01-27 20:33 UTC (2 hours ago)
(HTM) web link (www.jvt.me)
(TXT) w3m dump (www.jvt.me)
| guessmyname wrote:
| As someone who's been using Go since 2013 at commpanies like
| Apple, Microsoft, and Uber, this all seems quite unnecessary.
|
| That said, if it helps people do "their thing" in what they
| believe is an easier (more straightforward) way, then I welcome
| the new changes.
| teeray wrote:
| Given Go's approach to "metaprogramming" has long relied on
| tools written in Go, this does seem like a feature gap that
| needed closing. Even the introduction of `go generate` long ago
| formalized this approach, but still left installing the tools
| as an exercise for the reader. You can't have consistent code
| gen if you don't have consistent tooling across a team/CI.
| GauntletWizard wrote:
| I am both strongly of the opinion that this was already done
| much better in Bazel, and that the go-native version seems
| clean, clear, and simple and should probably be adopted by pure
| go shops.
|
| The digraph problem of build tooling is hardly new, though the
| ability to checksum all of your build tools and executables and
| mid-outputs to assure consistency is relatively new to
| feasibility. Bazel is a heavy instrument and making it work as
| well as it does was a hard problem even for Google. I don't
| know anyone making the same investment, and doubt it makes the
| slightest hint of sense for anyone outside the fortune 500.
| syvolt wrote:
| 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.
| jamietanna wrote:
| Yeah, I'm still rather excited about it, but less-so given it
| /does/ impact the `go.mod` for consumers
| movedx wrote:
| What solution would you propose?
| rplnt wrote:
| At least a comment if not its own section.
| remram wrote:
| So it's just dev-dependencies?
| jamietanna wrote:
| Yep, that's the intent
| imiric wrote:
| 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.
| bjackman wrote:
| 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 dunno if that's just lack of
| experience but it didn't quite seem ready for small projects.
|
| Maybe Nix is the solution but that has barrier to entry more at
| the human level - it just seems like a Way of Life that you have
| to dive all the way into.
|
| Nonetheless, maybe I should try diving into one or both of those
| tools at some point.
| sunshowers wrote:
| (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 certain
| tradeoffs that don't quite work in a more distributed model.
|
| Bazel is also in Java I believe, which is a bit unfortunate due
| to process startup times. On my machine, `time bazelisk --help`
| takes over 0.75 seconds to run, compared to `time go --help`
| which is 0.003 seconds and `time cargo --help` which is 0.02
| seconds. (This doesn't apply to buck2, which is in Rust.)
| 6keZbCECT2uB wrote:
| 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 adoption, cross platform support, and supported
| more locked down use cases like going through mirrors, not
| having root, not controlling file paths, etc. What Bazel gets
| from this is a generic solution for package management with
| better version solving for build rules, source dependencies and
| binary dependencies. By sourcing binary deps from conda forge,
| you get a midpoint between deep investment into Bazel and
| binaries with unknown provenance which allows you to
| incrementally move to source as appropriate.
|
| Additional notes: some requirements limit utility and approach
| being partial support of a platform. If you require root on
| Linux, wsl on Windows, have frequent compilation breakage on
| darwin, or neglect Windows file paths, your cross platform
| support is partial in my book.
|
| Use of Java for Bazel and Python for conda might be
| regrettable, but not bad enough to warrant moving down the list
| of adoption and in my experience there is vastly more Bazel out
| there than Buck or other competitors. Similarly, you want to
| see some adoption from Haskell, Rust, Julia, Golang, Python,
| C++, etc.
|
| JavaScript is thorny. 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. I haven't seen too
| much demand for JavaScript bindings to C++ wrappers around a
| Rust core that uses C core libraries, but I do see that for
| Python bindings.
| sunshowers wrote:
| > 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.
| wordofx wrote:
| Are we just copying .NET now?
| movedx wrote:
| What's wrong with copying from other projects if they're indeed
| offering good ideas worth copying? You say it as if the Golang
| community MUST only ever have unique ideas no one else has ever
| thought of -- something that's increasingly rare and unlikely.
___________________________________________________________________
(page generated 2025-01-27 23:00 UTC)