Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to start a Go project in 2023

boyter.org

Post reply on HN
Print view View original

101–110 of 205 posts

Re: How to start a Go project in 2023

#101

Post by fsociety »

ownagefool wrote: post #98
lima wrote: post #17

How 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…

So, I don't bother with vendoring my dependencies ( usually ), but you have it the wrong way round. Vendoring would make it more likely you're gonna review the changes, be ause you can quickly eyeball whether or not changes look significant, which is something you often won't get out of a go.sum change.

Unless you import a dependency which totals several hundred thousand lines of code.

Re: How to start a Go project in 2023

#102

Post by andrenth »

jzelinskie wrote: post #4

Things I can't live without in a new Go project in no particular order: - https://github.com/golangci/golangci-lint - meta-linter - https://goreleaser.com - automate release workflows - https://magefile.org - build tool that can version your tools - https://godoc.org/github.com/ory/dockertest/v3 - run containers for e2e testing - https://github.com/ecordell/optgen - generate functional options - https://golang.org/x/…

> - https://godoc.org/github.com/ory/dockertest/v3 - run containers for e2e testing

For this there is also the testcontainers project, which has support for Go and other languages.

https://golang.testcontainers.org/

Re: How to start a Go project in 2023

#103

Post by opportune »

sureglymop wrote: post #27

Genuine question.. I'll often see Golang pretty heavily criticized here on hacker news. Either that or people say it's a boring language and not worth learning when there is something more interesting (usually referring to Rust or Zig). Why does it have such a bad image? Personally i like it as an alternative for python because: 1. It can build binaries that just work for most architectures quickly. 2. It has nice c-…

Golang is IMO the best applications language. Most of my criticisms of it would be that it makes some systemsy things clunky, and because of garbage collection it just isn’t ideal for some systemsy stuff.

I personally hate the empty interface and definition shadowing of Go but that could be just me not “getting it”. Fortunately at work we don’t use that too often

I think most of the criticism is from people like me coming from C++. I am continually baffled that people write web backends in Python and Node at all, to me they seem so inappropriate that criticizing them would be a waste of time. I would consider Go to be much much better overall, and thus worthy of actual criticism

Re: How to start a Go project in 2023

#104

Post by avgcorrection »

sureglymop wrote: post #27

Genuine question.. I'll often see Golang pretty heavily criticized here on hacker news. Either that or people say it's a boring language and not worth learning when there is something more interesting (usually referring to Rust or Zig). Why does it have such a bad image? Personally i like it as an alternative for python because: 1. It can build binaries that just work for most architectures quickly. 2. It has nice c-…

> Genuine question..

There have been about a hundred “why Go”/“why not Go” threads on Hacker News already.

Re: How to start a Go project in 2023

#105

Post by sethammons »

lima wrote: post #17

How 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…

I'm on the vendor bandwagon; always have been. I don't want a github outage to dictate when I can build/deploy. Yes, that happened. That is why we vendor :).

Now you can set up a proxy server; however, I don't want to do that. I'm pretty sure I have a few vendored packages that no longer exist at their original import path. For code reviews, we put off checking in the vendor path til the end if possible.

Re: How to start a Go project in 2023

#106

Post by didip »

lima wrote: post #17

How 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 is a benefit to using "go mod vendor". Some corporate environments lock down their CI/CD pipelines. By vendoring everything, the CI/CD does not need to make external HTTP calls.

Re: How to start a Go project in 2023

#107

Post by dilyevsky »

0zemp2c wrote: post #39
lima wrote: post #17

How 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…

vendoring is a bit of project smell, but for large teams it removes the confusion of who has what version of a dependency unfortunately most teams don't schedule a periodic `go mod tidy` so you just end up with ancient deps most people never read the code of the deps they pull in, so I don't think vendoring provides any security assurances

> it removes the confusion of who has what version of a dependency

go.mod/sum files already remove that confusion as it’s their intended purpose

Re: How to start a Go project in 2023

#109

Post by eweise »

maxmcd wrote: post #65

Please 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)…

Looks like more boilerplate to me.

Re: How to start a Go project in 2023

#110

Post by Daegalus »

I would like to mention Magefile. We recently have been using it over makefiles and it has been amazing. Removes more non-go dependencies. You write your files in Go, and it all works really well.

https://magefile.org

Between that, goreleaser, 2-stage dockerfiles, static binaries, etc. It all just works so well and only needs Go for most things.

Recently for actual stuff we have been using Exho, Zerolog, and fairly common libraries for most tools.

Post reply on HN