121–130 of 207 posts
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.
Go being garbage collected and still beating v8 is one hell of an achievement.
If you need faster Go Http you're using the wrong tool.
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 agree — tools should be shared artifacts that the team downloads and can guarantee are the same for everyone. I usually setup a flake.nix for everyone but flox, earthly, devenv, jetify, are all great alternatives. Ideally your tools are declaratively configured and shared between your team and your CI/CD environment, too. The `go tool` stuff has always seemed like a junior engineering hack — literally the wrong too…
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…
Thank you for working on it. It is a nice feature and still better than alternatives. I'm not a library author and I try to be careful about what dependencies I introduce to my projects (including indirect dependencies). On one project, switching to `go tool` makes my go.mod go from 93 lines to 247 (excluding the tools themselves) - this makes it infeasible to manually review. If I'm only using a single feature of a…
now, do you care about some development tool you're running locally has a security issue? if yes, you needed to update anyway, if not, nothing changes.
Earlier quoted context omitted.
> Why do we need separate build systems for every language? Because being cross-language makes them inherit all of the complexity of the worst languages they support. The infinite flexibility required to accommodate everyone keeps costing you at every step. You need to learn a tool that is more powerful than your language requires, and pay the cost of more abstraction layers than you need. Then you have to work with…
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…
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 pure-Go projects, or pure-Rust projects, I don't need any of this. npm, go, and rust/cargo packages are uniform, and trivial to build with their built-in basic tools when they don't have C/C++ dependencies.
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…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
This take absolute boggles the mind. You don't want people compiling your code with different versions of tools so you have to debug thousands of potential combinations of everything. You don't want people running different versions of formatters/linters that leave conflicting diffs throughout your commit history.
so where does it stop? let's include version of OS on laptop of people who edit code? it is getting ridiculous. you got to draw a line somewhere. in my opinion, "if dependency code is not linked nor compiled-into nor copied as a source (e.g. model weights, or other artefacts) then it must not be included into dependency tree of project source code" that still means, you are free to track versions/hashes/etc. of tools…
Does everyone need to use the same IDE? Obviously not. Same C++ compiler? Ideally yes. (And yes you can do that in some cases, e.g. Bazel and its ilk allow you to vendor compilers.)
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…
No, it doesn't. You can use "go tool -modfile=tools.mod mytool" if you want them separate.
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.
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…
Did you consider having tool be an alias for indirect? That would have kept a single dependency graph per module, while still enabling one reading one’s go.mod by hand rather than using ‘go mod’ to know where each dependency came from and why?
I know, a random drive-by forum post is not the same as a technical design …