Hacker News Reader

Comment by denysvitali | Hacker News Reader

`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

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.

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?

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

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"

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.

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.

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.

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.

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.

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.

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.

In that case, it would have been necessary to specify the language they come from. The only hints given were 'classes' and 'modules'. Is it Java, Python, JavaScript, C++, Swift, Ruby, VB.NET? All these languages have classes and modules, and they all draw the line of encapsulation at different layers.

In many ways this just took what people were already doing with other languages and codified it.

The main benefit is that you can easily figure out what is where!

> The main benefit is that you can easily figure out what is where!

Navigating unfamiliar Go codebases yields very few surprises: things are almost always where I expect to find them, and it's great! This is hardly the case with other languages, where I have to rely on grep or trace function-calls

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

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/73ffd326d88483df6b1cb66e8ed1... describes

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.

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

    $ go run ./cmd/pathto/cli

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.

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)

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

Huh. Learned something today. Thank you.

Reply on news.ycombinator.com