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.

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

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.

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.

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.