project-layout

Standard Go Project Layout

Explore on GitHub Read Hacker News discussions

22Distinct people

22Mentions

0Explicit recommenders

56.7KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Standard Go Project Layout

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year22 dated mentions

Observed mentions: 2018-03-26 21:54:18 UTC to 2024-02-29 16:40:03 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	4	0	4
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	3	0	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	0	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	6	2	4
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	0	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	3	0	3

What Hacker News says

4 sources

Memosyne·Dec 11, 2018

I try to adhere to https://github.com/golang-standards/project-layout, but I find that most repositories just have their own way of doing things. I really wish Go provided a standard structure for organizing projects, as I find it increasingly difficult to understand dozens of different structures.

In Just tell me how to use Go Modules

shivylp·Nov 29, 2018

Thanks for the feedback. The layout used here is not something I came up with. It's an emerged pattern from popular open source projects. Like you said, most probably they all started with simple package and as the project grew abstracted out things finally leading to a similar layout. The layout itself is another community effort (https://github.com/golang-standards/project-layout). This is not to say that the layout is a standard or the best possible one. It has it's advantages and disadvantages (a whole git repository and a blog article is dedicated to describe both aspects. Hence, I will not get into that discussion here). I chose the layout simply because it's already a well documented one. That being said, I will be more than happy to see other layout and even refactor the structure. Open source projects generally are not typical we

Read the rest

b apps or REST API services. They are platforms or tools like docker, kubernetes, Hugo etc. While these projects are good usecases for studying golang code, they feel very complex due to their specific non-simple (if not complex) domain. My idea was to have a web app and API service project which has dead simple domain but highlights the coding practices so that newcomers can read and understand without having to understand what containers are etc. Few other clarifications I would like to make: - every directory is not essentially a package in Go. Only directories that have at least one go file are packages. Internal and PKG are not supposed to be packages in that sense. They are just a superficial boundaries between internal and public code. - web directory is not a package in this project.. it contains static asset files. - simplicity is something i absolutely love. That is the main reason I like golang. If you look past the outer structure of the project and dig into the code and packages, I think you will see the simplistic design inside. My other projects (e.g. https://github.com/spy16/radium) follow the simplistic method you explained.

In Show HN: A sample project for Golang

mneves·Nov 28, 2018

This is a useful repo for how to structure a Go project: https://github.com/golang-standards/project-layout

In Show HN: A sample project for Golang

programd·Mar 26, 2018

The major problem I have with the proxy is that now I have yet another system to keep track of, update, secure, backup and maintain. At least with vendoring I keep all of my code pinned in one portable repo and all I really need is dep and git. If I clone or backup the repo I don't have to think about cloning the state of the proxy also to get my code to compile. I don't see that any serious business would be very enthusiastic about adding a code proxy as yet another cog in their development pipeline. One of the main appeals of Go is that it reduces many pain points of a development environment As a counterexample see e.g. the insane requirements of the Javascript web development ecosystem. I also have some reservations about getting developers to adhere to a versioning repo layout standard - that /path/to/v2/ proposal and semantic versio

Read the rest

ning - absent any automated tools to enforce it (see cats, herding of). How many of the many Go github repos follow the recommended cmd/pkg code layout [0]? Not many. My cynical notion is that anything that's not automated out of the box is going to quickly run into the inevitable proclivity of humans to be messy. Having said all this, I do think the discussion is worthwhile. My hope is that rather then completely switching dependency management systems the discussion identifies the things which are still painful with dep and fixes them. Let's face it, the vast majority of projects out there really don't need anything more complicated then dep, so I would hate to see it abandoned. [0] https://github.com/golang-standards/project-layout

In A Proposal for Package Versioning in Go