[scaryclam]

Genuine question as I've only dabbled in Go, but I've heard complaints from other dabblers that Go seems to encourage large files rather than breaking things up in a more modular fashion. Is that a reality? Or has the complainer just been unlucky in the code they've viewed?

[fmpwizard]

I have been using Go for about 4 years at work and I would say they have been unlucky with the code they have looked at. You have the freedom to organize your code as you wish, you can easily go from one extreme to the other, one function per file to 1000 in one file. The only thing that isn't encouraged is to have very small packages, for example, if your project ends up split into 10 packages, but each of them is just one file (or one code file plus a test file), then most Go developers would suggest to group more files into a single package.

[sethammons]

To add some meat onto that: a package should be usable (and reusable) on its own. If you have a package that is a single function or struct, it is unlikely (but still possible!) to be useful on its own and likely requires the context of your other packages to be useful.

[Cthulhu_]

I've only dabbled myself, but I can see how that would start; I come from a Java background which forces you to have one module / class per file, but Go doesn't. It's very easy to start hacking up a thing, and it's easier in development to just keep it in one file. Of course, the nature of code is that it grows, so spend enough time there and it'll start growing. If you're familiar with the code (as in, you wrote it yourself), single files shouldn't be a problem.

It's not uncommon in other projects either, NodeJS for example has a relatively small number of large files (https://github.com/nodejs/node/blob/master/src/node.cc).

[geodel]

Go definitely prefers modular fashion. But definitely no gratuitous files/packages structure like Java where a dozen packages each with 2-3 files having nothing more than 50 lines of code out of which 30 are comments and imports of another dozen packages.

Unlike Java, Go does not have limitation of having each public class in its own file. So public symbols of any type can be put together in same file if it makes sense. Go prefers arranging code what makes sense for application functionality instead of auto-generated scaffolding like 'handlers', 'utils', 'assets', 'entities' etc like I do in my Java code.

[richardknop]

Most of Go code I was working on or contributed to usually has quite a split out structure and more complex structs are defined in multiple files with related methods grouped together. I have seen couple of Go packages which consist of one huge file but I think it's quite rare. Most people will structure their code into multiple files to keep it more readable/maintainable and file sizes relatively small.

[insertnickname]

I don't see any reason why Go would encourage large files. A Go package consists of every Go source file in a directory. You can use as many or as few files as you want per package.

[captncraig]

We don't really have the "one class one file" beat into us like in java or c#. That means you gotta think a little to see how a package naturally splits up. Some people are better at that then others.

[scaryclam]

Yeah, I found it a strange assertion to make, so was wondering if it held any water. Sometimes different languages have different ways of working, which seem odd to novices entering the space from a different background, so I didn't want to assume that they were wrong.

Looks like it may be a case of coming across some less well written projects and making assumptions about the entire language, which is nice as Go seems fun :)