是否建议将程序源（而不是lib源）保存在单个文件中？

Question

I am making my first steps into go and obviously am reasoning from what I'm used to in other languages rather than understanding go specificity and styles yet.

I've decided to rewrite a ruby background job I have that takes ages to execute. It iterates over a huge table in my database and process data individually for each row, so it's a good candidate for parallelization.

Coming from a ruby on rails task and using orm, this was meant to be, as I thought of it, a quite simple two files program : one that would contain a struct type and its methods to represent and work with a row and a main file to operate the database query and loop on rows (maybe a third file to abstract database access logic if it gets too heavy in my main file). This file separation as I intended it was meant for codebase clarity more than having any relevance in final binary.

I've read and seen several things on the topic, including questions and answers here, and it always tend to resolve into writing code as libraries, installing them and then using them into a single file source (in package main) program.

I've read that one may pass multiple files to go build / run, but it complains if there is several package name (so basically, everything should be in main) and it doesn't seem that common.

So, my questions are :

• did i get it right, and having code mostly as library with a single file program importing it the way to go ?
• if so, how do you deal with having to build libraries repeatedly ? Do you build / install on each change in library codebase before executing (which is way less convenient that what go run promise to be) or is there something common I don't know of to execute library dependent program quick and fast while working on those libraries code ?

Answer 1

No.

Go and the go tool works on packages only (just go run works on files, but that is a different story): You should not think about files when organizing Go code but packages. A package may be split into several files, but that is used for keeping test code separated and limiting file size or grouping types, methods, functions, etc.

Your questions:

did i get it right, and having code mostly as library with a single file program importing it the way to go ?

No. Sometimes this has advantages, sometimes not. Sometimes a split may be one lib + one short main, in other cases just one large main might be better. Again: It is all about packages and never about files. There is nothing wrong with a single 12 file main package if this is a real standalone program. But maybe extracting some stuff into one or a few other packages might result in a more readable code. It all depends.

if so, how do you deal with having to build libraries repeatedly ? Do you build / install on each change in library codebase before executing (which is way less convenient that what go run promise to be) or is there something common I don't know of to execute library dependent program quick and fast while working on those libraries code ?

The go tool tracks the dependencies and recompiles whatever is necessary. Say you have a package main in main.go which imports a package foo. If you execute go run main.go it will recompile package foo transparently iff needed. So for quick hacks: No need for a two-step go install foo; go run main. Once you extract code into three packages foo, bar and waz it might be a bit faster to install foo, bar and waz.