Hacker News Reader

Comment by nsf | Hacker News Reader

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.

View on HN

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.

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.

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! :) )

Reply on news.ycombinator.com