Hacker News Reader

Comment by linkdd | Hacker News Reader

Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine.

But once the code base grows, it easily becomes a tangled mess.

My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).

View on HN

You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory.

In which directory to store files is an incredibly small and minor detail though.

> nothing really stopping you, but it's not the usual approach

In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily.

> In which directory to store files is an incredibly small and minor detail though.

Yeah it's a small detail, but it is important to me to not get lost in a directory tree.

Random example taken from a github search: https://github.com/gofiber/fiber

Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance?

For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works.

I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.

Could this be an issue with Go's built in build system rather than go the language ? At work I use go with Bazel and found it okay with regard to source layout, similar to my experience with c++. I don't have experience with go outside of Bazel though.

When I try to decide if i want to use a language, I look at its ecosystem.

It may have the best features in the world, but if the ecosystem is not there, it will be a pain to use it.

On the opposite, a language can have the worst features and a great ecosystem, for example Python is slow but as great scientific tools, or Javascript has a weird "typing system" but has tons of tools in every domain to make the best of it.

I don't know Bazel though, I'll take a look at it, thanks!

This pattern or close variants or subsets are fairly common:

https://github.com/golang-standards/project-layout

Reply on news.ycombinator.com