"go mod init ".
Minor improvement over "mkdir -p $GOPATH/src/path/in/vcs/remote/"
/s
How to start a Go project in 2023
61–70 of 205 posts
Re: How to start a Go project in 2023
#62> The solution is to upgrade [Go language] after a week or so
I personally have a habit of updating only when the next patch version is out. It saved be countless hours of debugging and frustration.
Re: How to start a Go project in 2023
#63How to start a new Go project: go mod init mymodule Go's default toolchain is fine, everything else is optional. Some questionable advice in the article: - Vendoring dependencies using "go mod vendor" is not a good default workflow - it bloats the repo, the checked in code is impossible to review, and is generally a pain to keep up to date. Don't, unless you really have to. - There's no point in stripping a binary or…
> There's no point in stripping a binary or even using UPX on it unless you're targeting extremely low memory environments
I really dislike absolutes like this.
My target is 30,000+ servers and distributing a binary to all of them is a lot easier when it is 3m than when it is 26m.
Re: How to start a Go project in 2023
#64I see $GOPATH is no longer strictly needed, which is nice. But what's the deal with $GOROOT? I seem to always need it set but I don't know if that's just my workflow or force of habit.
People should essentially never set GOROOT. It's mostly a holdover. For example, Ian Lance Taylor on the core Go team wrote [0] somewhat recently:
"It's a special purpose hook that is almost never needed".
[0] https://groups.google.com/g/golang-nuts/c/qDhJbkE1QeY/m/JoV2...
Re: How to start a Go project in 2023
#65Please don't use build tags for integration tests: https://peter.bourgon.org/blog/2021/04/02/dont-use-build-tag...
Along with the issues listed here you will run into issues with editors not building/linting your tests files because they have build tags that the editor is unaware of.
You can also put the environment variable in a TestMain[1] to cover an entire package of integration tests:
func TestMain(m *testing.M) {
if os.Getenv("RUN_INTEGRATION_TESTS") == "" {
fmt.Println("Skipping integration tests")
return
}
os.Exit(m.Run())
}
Re: How to start a Go project in 2023
#66How to start a new Go project: go mod init mymodule Go's default toolchain is fine, everything else is optional. Some questionable advice in the article: - Vendoring dependencies using "go mod vendor" is not a good default workflow - it bloats the repo, the checked in code is impossible to review, and is generally a pain to keep up to date. Don't, unless you really have to. - There's no point in stripping a binary or…
> There's no point in stripping a binary or even using UPX on it unless you're targeting extremely low memory environments I really dislike absolutes like this. My target is 30,000+ servers and distributing a binary to all of them is a lot easier when it is 3m than when it is 26m.
I don't really believe that, at the speed of nic it makes pretty much 0 difference even on 30k servers. Shaving couple of ms at worse few seconds vs modifing a binary, def not worth it.
Re: How to start a Go project in 2023
#67The article mentions GOW[0] for a file watcher. If anyone is looking for a non-go specific one, I've really enjoyed reflex[1]. Makes it super easy to reload different parts of a project based on what type of file has changed. [0] https://github.com/mitranim/gow [1] https://github.com/cespare/reflex
Just to add to the list there is also https://github.com/cosmtrek/air
Re: How to start a Go project in 2023
#68Earlier quoted context omitted.
UPX only means smaller files on the disk, but it comes with a cost: it tends to increase memory requirements, because the binary on the disk cannot be mapped to memory anymore. Unless it's uncompressed somewhere in the filesystem. Worse, if you run multiple instances of the same binary, none of them can be shared. A bit simplified, without UPX, 100 processes of 100 MB binaries requires only 100 MB RAM for the code, b…
Can you expand on this a bit? I use upx at work to ship binaries. Are you saying these binaries have different memory usage upx’d than they do otherwise?
Every instance of a program will use an amount of ram equal to the uncompressed size.
If the application is uncompressed, the uncompressed executable will be loaded into ram 1 time and be reused by every instance of the application.
Re: How to start a Go project in 2023
#69One thing I wish there was better support for is live debugging and stepping through code.
I absolutely love the integration in VSCode with the official Go extension. I can debug a running web server with delve with minimal config. Same for tests. Just experiment with the options, there are quite a lot, and unfortunately some not very well documented like gopls ones, at least last time i checked.
Re: How to start a Go project in 2023
#70Earlier quoted context omitted.
Cobra is just so… intense and complicated. It has it's place but Google's Subcommands is enough for 99.9% of projects I've worked on - https://github.com/google/subcommands
I've built many CLIs with Cobra and haven't found it all that intense. I've built incredibly simple, single function CLIs up to some incredibly advanced CLIs that the entire company relies on daily. I like Cobra because it gives you a great place to start, with tons of stuff "for free". Things like spellcheck on commands like if you type "mycli statr", you might get a response "mycli statr command not found. Did you…
>spellcheck on commands
I prefer to just type "fuck":