Do you want me to write code like that? https://github.com/Mikkeren/FizzBuzzEnterpriseEdition

Sure, but honestly the original complaint was implying that godit is badly structured. Yes, I don't use Go packages for it, because it's just a small 5k lines of code project and I don't need to use 100 packages to avoid namespace clashes. I use a separate file for most of editor modes and concepts, what else the author wants me to do? Hence, the irony in the answer.

Sorry, my original comment was way harsher than necessary. I wasn't meaning to imply you had structured it badly, the use of files is certainly clear.

I was just wondering if the lack of folders was a typical Go thing. For example, I probably would have something like modes/{all _mode.go files}, and maybe view/{view files}, but I've never touched Go, so I was wondering whether this was unidiomatic.

Well in Go there are no makefiles, but there is a tool called "go". It can build stuff for you. It maintains an assumption that all *.go files within the same directory belong to the same package. So you can't actually store multiple packages in the same dir or span files of one package across multiple dirs and use the go tool at the same time. Since the go tool makes like really easier, I choose to obey its conventions. That's why all files are in the same dir.

And I can't just add "modes" and "view" packages, because there are parts in them which depend on core concepts, which leads me to another "core" package or something. And that's 3 packages already. When there's 3, there's 4. It's easier the way it is.

Ah, ok, that does sound much easier.

(Thanks for the explanation! :) )

You can do either. Folders are packages, so if you had /modes, that would be a modes sub-package which could be included in the top level code with import.

A couple of weeks ago I was searching for go programs in order to see examples of how I could organize a toy project I was starting. I found godit and after reading the source I think it is a good way to organize a small project. Eventually you can start moving functionality to packages once they grow big enough.

And the tooling helps. There is no Makefile and no instructions, so I tried `go build` and it just works.

go does have file organisation. You can create packages in directories and nest them and the tooling will handle it easily.