4 ms·

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

by mqus 3y ago

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.

cpuguy83 3y ago
This one was voted down but there is a good point here. There is no way to figure out what binaries there are (maybe you could make `go list` show all the `package main`s?, not sure). 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.
- NewJazz 3y ago
  Temporary gopath, "go install ./...", list contents of bin.
lynndotpy 3y ago
This is what Rust does with `cargo run`; I think Poetry for Python tries to do the same thing but I haven't used it in awhile.
thayne 3y ago
That is how `cargo run` for rust works by default. As long as there is just one executable. If you have multiple executables in a project you do need to specify which one though.
ryukoposting 3y ago
Or, even better, `./main`
- dewey 3y ago
  That's not better but confusing as the "main" binary doesn't exist (The main point of go run), and you'd always have to type the full name as you can't autocomplete it.
  - ryukoposting 3y ago
    Who said it needs to be a binary? Name the source file "main" and put a shebang at the top.
sapiogram 3y ago
You also have to know whether it's `cd cmd; go run main.go` or just `go run cmd/main.go`. And you have to know to set CGO_ENABLED=0 if you want to run it on Linux instead of MacOS.
Zababa 3y ago
I agree, especially since 'go build', 'go install', 'go test', 'go generate', 'go vet', 'go fmt', etc will do what you expect when you run them without parameters. I think the difference may be that 'go run' expect one package to run, while the others can take multiple. If you have a library (no top-level main package) that comes with two tools foo and bar, I don't think 'go run' could know which package to run. Example tree: go.mod go.sum library.go // package library cmd/foo/foo.go // package main cmd/bar/bar.go // package main
mariusor 3y ago
> I don't think it's simple. I mean, it kinda is. If you're a Go developer that went further than hello world, you will probably be aware of these two possibilities: If . contains a "main" package then it's "go run .", otherwise the source for the binaries probably reside in "./cmd/X" and you have to run "go run cmd/X". You can probably find Go projects that don't follow these rules, but I doubt anyone would want to interact with them.
eadmund 3y ago
'go run cmd/COMMAND' is what I like best. I normally don’t bother descending further than the root of a project in the shell because all my other interactions are in Emacs rather than a terminal (I rarely use the shell in Emacs because the shell is so much less powerful for most stuff). Maybe that’s weird. I think folks who live in vi spend a lot more time bouncing around directories in the shell.

by mqus 3y ago

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.

cpuguy83 3y ago

This one was voted down but there is a good point here. There is no way to figure out what binaries there are (maybe you could make `go list` show all the `package main`s?, not sure). 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.

NewJazz 3y ago
Temporary gopath, "go install ./...", list contents of bin.

lynndotpy 3y ago

This is what Rust does with `cargo run`; I think Poetry for Python tries to do the same thing but I haven't used it in awhile.

thayne 3y ago

That is how `cargo run` for rust works by default. As long as there is just one executable. If you have multiple executables in a project you do need to specify which one though.

ryukoposting 3y ago

Or, even better, `./main`

dewey 3y ago
That's not better but confusing as the "main" binary doesn't exist (The main point of go run), and you'd always have to type the full name as you can't autocomplete it.
- ryukoposting 3y ago
  Who said it needs to be a binary? Name the source file "main" and put a shebang at the top.

sapiogram 3y ago

You also have to know whether it's `cd cmd; go run main.go` or just `go run cmd/main.go`. And you have to know to set CGO_ENABLED=0 if you want to run it on Linux instead of MacOS.

Zababa 3y ago

I agree, especially since 'go build', 'go install', 'go test', 'go generate', 'go vet', 'go fmt', etc will do what you expect when you run them without parameters. I think the difference may be that 'go run' expect one package to run, while the others can take multiple. If you have a library (no top-level main package) that comes with two tools foo and bar, I don't think 'go run' could know which package to run. Example tree: go.mod go.sum library.go // package library cmd/foo/foo.go // package main cmd/bar/bar.go // package main

mariusor 3y ago

> I don't think it's simple. I mean, it kinda is. If you're a Go developer that went further than hello world, you will probably be aware of these two possibilities: If . contains a "main" package then it's "go run .", otherwise the source for the binaries probably reside in "./cmd/X" and you have to run "go run cmd/X". You can probably find Go projects that don't follow these rules, but I doubt anyone would want to interact with them.

eadmund 3y ago

'go run cmd/COMMAND' is what I like best. I normally don’t bother descending further than the root of a project in the shell because all my other interactions are in Emacs rather than a terminal (I rarely use the shell in Emacs because the shell is so much less powerful for most stuff). Maybe that’s weird. I think folks who live in vi spend a lot more time bouncing around directories in the shell.