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

71–80 of 207 posts

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

#71

Post by 0x696C6961 »

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 .

The way it's implemented is the way that almost everyone already does it. It's just more convenient now.

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

#72

Post by dwattttt »

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

Earlier quoted context omitted.

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

Rust does permit multiple incompatible versions of the same library in the same environment. The types/objects from one version are distinct from the types/objects of the other, it's a type error to try mix them.

But you can use two versions of the same library in your project; I've done it by giving one of them a different name.

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

#73

Post by [deleted] »

0x696C6961 wrote: post #71
Groxx wrote: post #65

Earlier quoted context omitted.

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

The way it's implemented is the way that almost everyone already does it. It's just more convenient now.

[deleted]

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

#74

Post by Groxx »

0x696C6961 wrote: post #71
Groxx wrote: post #65

Earlier quoted context omitted.

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

The way it's implemented is the way that almost everyone already does it. It's just more convenient now.

"Popular" and "good" have no relation to each other. They correlate fairly well, but that's all.

Blending those dependencies already causes somewhat frequent problems for library owners / for users of libraries that do this. Encouraging it is not what I would consider beneficial.

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

#75

Post by mook »

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.

There's also the (draft) release notes: https://go.dev/doc/go1.24 And the docs: https://go.dev/doc/modules/managing-dependencies#tools

I've done the blank import thing before, it was kinda awkward but not _that_ bad.

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

#77

Post by thayne »

jeffbee wrote: post #32
sunshowers wrote: post #22

Earlier quoted context omitted.

(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 certa…

This is likely because you are running it in some random PWD that doesn't represent a bazel workspace. When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time. Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.

> When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.

It still has a slow startup time, bazel just works around that by using a persistent daemon, so that it is relatively fast after as long as the daemon is running.

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

#78

Post by morepedantic »

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…

Brazil performs dependency resolution in a language-agnostic way.

https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6...

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

#79

Post by pjmlp »

pansa2 wrote: post #56
munificent wrote: post #43

Earlier quoted context omitted.

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…

> No Python evangelist wants to tell users that step 1 of getting up and running with Python is "Install Ruby". True, but the Python community does seem to be coalescing around tools like UV and Ruff, written in Rust. Presumably that’s more acceptable because it’s a compiled language, so they tell users to “install UV” not “install Rust”.

I tend to think that is more Rust community using Python, and RIIR stuff, than Python community themselves.

I know Python since version 1.6, and this has never been a thing until Rust.

Same applies to the RIIR going on JavaScript side.

Including tools that were already written in compiled languages, but of course weren't Rust, or had an idea to make a startup around them.

Post reply on HN