6 ms·

`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

pizzafeelsright 3y ago
Huh. Learned something today. Thank you.
pizzafeelsright 3y ago
Huh. Learned something today. Thank you.
breadchris 3y ago
great point, this is the one thing that I wish was more intuitive. You don't have to do this if main.go is the only file in the main package and all other code is referenced by a package.
aeturnum 3y ago
This is a good tip! It also captures what has been frustrating about golang for me. The language feels a bit stuck between simple default cases and allowing complexity. 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.
- mseepgood 3y ago
  I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?
  - skissane 3y ago
    > I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that? The problem is many Go tutorials start out by teaching the complex case first and leave the simple case to later (if they cover it at all).
    - rtheunissen 3y ago
      Maybe it is because the simple way requires knowledge of packages, which are covered later perhaps, since many tutorials go straight to "go run helloworld.go"
      - skissane 3y ago
        You don't need to cover packages. You could just say this: the standard convention is that the source for each Go program lives in its own directory, and it starts running the code in a file called `main.go`. To run the Go program in the current directory, run `go run .` Introducing the concept of "packages", and the fact that the directory is a package, can be deferred until later.
  - aeturnum 3y ago
    It's not this specifically - it's when this "kind of thing" comes up in golang in particular. Every language needs to pick when to hold back complexity and when to make the user deal with it and I just personally dislike golang's particular balance. I also respect the work! It just irritates me.
IggleSniggle 3y ago
Yup. This was the main thing that bit me when I was first getting into Go. File names are kind of like classes, and directories are kind of like modules. The encapsulation sits at a slightly different layer than you might expect.
- mseepgood 3y ago
  Your expectations may vary depending on where you come from. There are many places one can come from. It's advisable to minimize expectations or assumptions when learning something new, as they could impede your learning process.
  - lanternfish 3y ago
    On the other hand, learning something tabula rasa takes way longer than if you scaffold it with assumptions. Otherwise, each new skill/language you learn would take as long as the first one.
  - IggleSniggle 3y ago
    Yes, absolutely. Thank you for clarifying what I was saying. Regardless of where you are coming from, it's likely to be the places where there unstated assumptions / cultural-norms that differ from your own where you will experience the biggest "lift" when encountering a new technology. The more a culture aligns with a "lowest common denominator," the more it will be readily understood, and the less it does, the more it will act as an exclusivity gate. Either could be desirable or undesirable depending on your goals. It's good to be aware of the dynamics so that you can make an informed choice about how to present your code.
  - deleted 3y ago
    [deleted]
  - ktm5j 3y ago
    It's natural to have expectations based on your experiences.. I think the person you replied to is just trying to help people who might misunderstand go based on those expectations. I think you're getting unnecessarily deep here.
38 3y ago
you can also do `go run hello.go world.go`, but yeah `go run .` is probably better
- c314 3y ago
  [dead]
devjam 3y ago
And if your main.go is in a sub-directory, e.g. cmd/pathto/cli/main.go: $ go run ./cmd/pathto/cli
lloeki 3y ago
Isn't it supposed to be `go run ./...`? (long time I didn't use Go, back then at least, using `.` instead of `./...` could cause subtle issues)
SPBS 3y ago
Fun fact: `go run .` was retrofitted on after `go run main.go` because go run was initially designed to only accept explicit filenames as an argument [1]. I can't imagine how people used to use `go run` without the ability to specify whole packages (globs don't work well because it includes test files as well). > Potential design based on discussion with proposal review: > go run [go flags] [single-package-or-*.go-list] [subprocess flags] before that it was just > go run [go flags] [*.go-list] [subprocess flags] [1] https://github.com/golang/go/issues/22726 https://github.com/golang/go/issues/22726
lenkite 3y ago
Wish `go run` worked for hashbang shell scripts. But you have to do a lot of hacks to make it work like: https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1e0bd https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1... describes
1vuio0pswjnm7 3y ago
This is not a tip. It comes straight from go help run "usage: go run [build flags] [-exec xprog] package [arguments...] Run compiles and runs the named main Go package. Typically the package is specified as a list of .go source files from a single directory, but it may also be an import path, file system path, or pattern matching a single known package, as in 'go run .' or 'go run my/cmd'." Nothing is said about go run main.go.

pizzafeelsright 3y ago

Huh. Learned something today. Thank you.

pizzafeelsright 3y ago

Huh. Learned something today. Thank you.

breadchris 3y ago

great point, this is the one thing that I wish was more intuitive. You don't have to do this if main.go is the only file in the main package and all other code is referenced by a package.

aeturnum 3y ago

This is a good tip! It also captures what has been frustrating about golang for me. The language feels a bit stuck between simple default cases and allowing complexity. 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.

mseepgood 3y ago
I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?
- skissane 3y ago
  > I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that? The problem is many Go tutorials start out by teaching the complex case first and leave the simple case to later (if they cover it at all).
  - rtheunissen 3y ago
    Maybe it is because the simple way requires knowledge of packages, which are covered later perhaps, since many tutorials go straight to "go run helloworld.go"
    - skissane 3y ago
      You don't need to cover packages. You could just say this: the standard convention is that the source for each Go program lives in its own directory, and it starts running the code in a file called `main.go`. To run the Go program in the current directory, run `go run .` Introducing the concept of "packages", and the fact that the directory is a package, can be deferred until later.
- aeturnum 3y ago
  It's not this specifically - it's when this "kind of thing" comes up in golang in particular. Every language needs to pick when to hold back complexity and when to make the user deal with it and I just personally dislike golang's particular balance. I also respect the work! It just irritates me.

IggleSniggle 3y ago

Yup. This was the main thing that bit me when I was first getting into Go. File names are kind of like classes, and directories are kind of like modules. The encapsulation sits at a slightly different layer than you might expect.

mseepgood 3y ago
Your expectations may vary depending on where you come from. There are many places one can come from. It's advisable to minimize expectations or assumptions when learning something new, as they could impede your learning process.
- lanternfish 3y ago
  On the other hand, learning something tabula rasa takes way longer than if you scaffold it with assumptions. Otherwise, each new skill/language you learn would take as long as the first one.
- IggleSniggle 3y ago
  Yes, absolutely. Thank you for clarifying what I was saying. Regardless of where you are coming from, it's likely to be the places where there unstated assumptions / cultural-norms that differ from your own where you will experience the biggest "lift" when encountering a new technology. The more a culture aligns with a "lowest common denominator," the more it will be readily understood, and the less it does, the more it will act as an exclusivity gate. Either could be desirable or undesirable depending on your goals. It's good to be aware of the dynamics so that you can make an informed choice about how to present your code.
- deleted 3y ago
  [deleted]
- ktm5j 3y ago
  It's natural to have expectations based on your experiences.. I think the person you replied to is just trying to help people who might misunderstand go based on those expectations. I think you're getting unnecessarily deep here.

38 3y ago

you can also do `go run hello.go world.go`, but yeah `go run .` is probably better

c314 3y ago
[dead]

devjam 3y ago

And if your main.go is in a sub-directory, e.g. cmd/pathto/cli/main.go: $ go run ./cmd/pathto/cli

lloeki 3y ago

Isn't it supposed to be `go run ./...`? (long time I didn't use Go, back then at least, using `.` instead of `./...` could cause subtle issues)

SPBS 3y ago

Fun fact: `go run .` was retrofitted on after `go run main.go` because go run was initially designed to only accept explicit filenames as an argument [1]. I can't imagine how people used to use `go run` without the ability to specify whole packages (globs don't work well because it includes test files as well). > Potential design based on discussion with proposal review: > go run [go flags] [single-package-or-*.go-list] [subprocess flags] before that it was just > go run [go flags] [*.go-list] [subprocess flags] [1] https://github.com/golang/go/issues/22726 https://github.com/golang/go/issues/22726

lenkite 3y ago

Wish `go run` worked for hashbang shell scripts. But you have to do a lot of hacks to make it work like: https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1e0bd https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1... describes

1vuio0pswjnm7 3y ago

This is not a tip. It comes straight from go help run "usage: go run [build flags] [-exec xprog] package [arguments...] Run compiles and runs the named main Go package. Typically the package is specified as a list of .go source files from a single directory, but it may also be an import path, file system path, or pattern matching a single known package, as in 'go run .' or 'go run my/cmd'." Nothing is said about go run main.go.