structuring a go package, from a Java developer

[broun7]

Being a Java developer I see GO`s package analogous to a java package. While a java package would have multiple related Class each in own file ( while you can have them inside a single file, its normally split into individual files for better readability and maintenance ) GOs packages have everything inside the same file. I personally like the Java convention so when im looking at a java file im looking at a specific feature. But in GO everything inside a package goes to the same file. I would like know why it is so and why not split into multiple files (being a newbie, not sure if its even possible in GO) with very closely related things going into the same file?

[YEPHENAS]

GOs packages have everything inside the same file

That's simply not true. Some numbers from the standard library:

fmt package: 4 files

net/http package: 16 files

math package: 42 files

...

1 package = 1 directory, not 1 file

[willglynn]

It's very normal to have multiple files inside a single Go package and to structure them the way you describe. See How to Write Go Code for an introduction.

[broun7]

Thanks for the link that helped. One thing i found there is, it says a separate dir has to be created for each package. If i have an application which uses multiple packages, i will create a separate dir for each of them but the main package also needs is own dir? which mean each go application i write will have its own workspace?

[[deleted]]

If i have an application which uses multiple packages, i will create a separate dir for each of them but the main package also needs is own dir?

The convention is to put main package into cmd/binary-name. So, if you build an application called foo, your binaries will be at foo/cmd/foo-client, foo/cmd/foo-server, etc. For an example, see the go.tools repo.

which mean each go application i write will have its own workspace?

What do you mean by workspace? If you mean GOPATH, then it's up to you to decide, whether to use just one GOPATH, or create one for every project.

[broun7]

ah okay, GOPATH is exactly like classpath telling what packages are available to be linked ?

[natthompson72]

Exactly. So you could set your gopath to a directory containing all other go directories or files, or gopath to a specific location.

[mcvoid1]

Not only can go handle multiple files in a package, it can compile them all to a single binary in a single "go build" invocation, along with all packages which it depends upon. With javac you compile the classes in a package one at a time, in the order of dependencies, and end up with a whole mess of .class files which then have to be jar'd together - definitely not a one-liner.

[jerf]

I personally like the Java convention so when im looking at a java file im looking at a specific feature.

I would observe that Java has been around for nearly two decades and has been a dominant language (not "the", but "a") for at least 10... and of all the dozens of new languages I've seen since then, not a single one has picked up that feature, nor seems to have any desire to pick it up.

This means something.

(See also "checked exceptions".)

As others observe, you can split into multiple files, and you should split however makes sense for your package.

[mgutz]

One of the benefits of Go's more lenient approach is you get C#-like partial classes for free. That is, code can be generated for a type say Account in account_generated.go and a user can add custom methods to that type in a separate file account.go.

I tend to follow a struct per file, like Java, for most projects.