11–20 of 173 posts
Earlier quoted context omitted.
Most of these examples don’t automatically fetch the dependencies. Having come from Python, Go’s tools are notably simple.
> Most of these examples don’t automatically fetch the dependencies. Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code . IMO those should be separate steps, and combining them together in one is not a good idea.
I don't think it's simple. Just `go run` would be far more simple. Right now I first have to figure out if its `go run .` or `go run cmd/main.go` or some other thing.
Beyond that there's no way to discover what build flags may be needed to give you the binary that the developer intended. Be it tags, ldflags, cgo support.
Earlier quoted context omitted.
Most of these examples don’t automatically fetch the dependencies. Having come from Python, Go’s tools are notably simple.
> Most of these examples don’t automatically fetch the dependencies. Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code . IMO those should be separate steps, and combining them together in one is not a good idea.
What's the point in making `go run` error out when it already knows what dependencies to get and how to get them.
Bazel does this for _all_ languages. I'm sure most other modern generic build systems do too.
AFAIK "go run" is trivial and for single-file scripts it's fine. But for more complex cases (like the NPM equivalent thing) I actually think it's a bit of a shame that it's even needed. I don't really know why we have per-ecosystem build systems (Maven, Go, cargo, whatever the hell you're supposed to do in Python these days, the nebula of web front-end tooling, etc etc).
Admittedly I do not really know the ins and outs of any of these systems in detail. I'm sure there are some good reasons why they exist under the hood.
go run mvdan.cc/sh/v3/cmd/gosh@latest -c ' go run github.com/mikefarah/yq/v3@latest n foo.bar.hello world | go run github.com/cezarsa/glolcat@latest'`go run main.go` breaks if your `main` module is divided into multiple files. Use `go run .` instead - it's shorter and it works with multiple files
Earlier quoted context omitted.
> Most of these examples don’t automatically fetch the dependencies. Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code . IMO those should be separate steps, and combining them together in one is not a good idea.
Why not ?
`go run main.go` breaks if your `main` module is divided into multiple files. Use `go run .` instead - it's shorter and it works with multiple files
I feel like there are two relatively distinct populations of go developer: those who love how easy it is to start (true!) and those who are frustrated by the compromises the language has made to allow for more complex cases (required!). There's also a hidden third population of people who no longer sing the praises of golang as a simple, straightforward language but accept its compromises and write productive code with it. Those people, I think, write fewer viral blog posts.
I don't think it's simple. Just `go run` would be far more simple. Right now I first have to figure out if its `go run .` or `go run cmd/main.go` or some other thing.