6 ms·
Setup for your next Golang project should be an empty "main.go". Let the project grow naturally.
by divan 7y ago
Setup for your next Golang project should be an empty "main.go". Let the project grow naturally.
- lowmagnet 7y agoDoing the most minimal thing is often the right answer in Go. I recently went down a rabbit hole before finding out that something supported timeout natively. I was glad to delete the code.
- heyoni 7y agoThat’s always the best feeling, unless you figure it out a year later, and then you just beat yourself up for it.
- maximente 7y agoright? goodness, the post itself even strongly implies this individual simply cannot let simple things be: > The list goes on and it never gets to the point that I'm actually satisfied with the setup...
- atomi 7y agoBut past that, there is a good GopherCon talk about structuring Go code: https://www.youtube.com/watch?v=oL6JBUk6tj0 https://www.youtube.com/watch?v=oL6JBUk6tj0 Code practically writes itself (in my opinion) if you structure it well.
- _wldu 7y agoYep, and a standard Makefile too.
- monocasa 7y agoWhat's wrong with starting out using go build, go run, and go test?
- pstuart 7y agoNothing at all. But the moment you move past that it's a nice standard way of encapsulating tasks related to the project.
- monocasa 7y agoSo there's no need to start with that is the point.
- tedunangst 7y agoFaster to type make than go build.
- divan 7y agoalias b='go build' `b` is even faster to type :)
- asymptotically2 7y agoDon't use a Makefile with a bunch of phony targets. Either make use of the dependency graph or use a shell script.
- ben0x539 7y agoI'm working with a bunch of people who occasionally start new Golang projects that are eventually maintained the just about the whole group. Everybody has their own idiosyncratic ways of setting up their new projects, so every time I switch to working on another project I have to spend some of my cognitive capacity figuring out and remembering what the natural way to nest directories, name config files, wire up build/deployment scripts etc was for this particular project. It's not the end of the world, but I think the effort required outweighs the benefit of natural growth, and any arbitrary, ill-fitting consistency is preferable to no consistency. imo, at some point, the worn-out "cattle, not pets" mantra applies to codebases too, not just infrastructure. So, I don't have any extremely strong opinions on project layout and if all of the unimportant decisions are already made for me, all the better. That said, I would never want to tell anyone "you must blindly follow this one particular structure". Rules are meant to be thoughtfully broken.
- rmetzler 7y agoI really like your approach here. There is one thing, I find very nice in Rails and other MVC projects and this is a standardized project setup. You can still bend and break the rules, but the mental effort is so much reduced and the programmer is able to concentrate more on code and doesn't need to think about structuring.
- loopz 7y agoLet's assume something can be called "Waterfall", there's a spectrum on the other side from "Agile": A) The less you know about something in advance, you want to iterate in small increments in order to learn&fail fast, pivot and have many small gains and something to show early (Agile). B) The more you know about something in advance (ie. re-implement Z on platform Y instead of X), you want more up-front design and re-use of already established patterns. Since the end result is mostly already known, you don't want to waste time&energy hunting down clever solutions, but spend shorter time on pure implementation. For a typical golang project you have some idea of scope, or purely convention/convenience, you could decide to setup according to minimal structure. Even though we know java-programmers will want to implement their "architecture" on the project filesystem-level, we don't have to go all the way to the other end of the spectrum either. A plain main.go file would require more refactoring, but hold the most promise in terms of freedom, innovation and creative input. But the Go-community have started to follow some minimal conventions already, so as to rein in the worst and unnecessary cases of divergence.