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

21–30 of 205 posts

Re: How to start a Go project in 2023

#21

Post by omneity »

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

Are there boilerplates that include things like this? (I’m coming from the JS/TS world)

Re: How to start a Go project in 2023

#22

Post by tptacek »

Go is pretty mainstream now, so if your editor is mainstream too, just keep using it and add its Go support; you don't need to pick a Go-optimized editor. The basic thing I think you really want is something like `goimports` (which you can just install), which automatically manages your imports for you and takes out 80-90% of the pain of Go's library usage policy.

Re: How to start a Go project in 2023

#23

Post by cratermoon »

Note that statically linked go binaries work in a docker image from scratch. This can be created with a multi-stage build where the builder image uses whatever OS you prefer, with any required packages. A build line such as

    RUN CGO_ENABLED=0 go build -o mybin -ldflags '-extldflags "-static"' -tags timetzdata
And the second stage like

    FROM scratch
    COPY --from=app-builder mybin mybin
    ENTRYPOINT ["/mybin"]
The builder can create users and groups, and the final image can import necessary certs like so:

    COPY --from=alpine:latest /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

Re: How to start a Go project in 2023

#25

Post by donatj »

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

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

Re: How to start a Go project in 2023

#27

Post by sureglymop »

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-like syntax without some of the headaches. 3. It seems to be really nice for creating apis or backends, especially for web projects. Lately i use it as an alternative to php, to build MPAs which are enhanced with htmx. 4. It seems very beginner friendly and easy to start with and has a non-gatekeepy community. There are also some things i don't like so much such as: 1. Goroutines and other go specific stuff 2. The dependency system requiring full import paths with urls. 3. The strictness about syntax etc. The fact that saving a file with an unused import will remove it in the ide.

But it overall seems much nicer than running node/js or python on the server side, no?

Re: How to start a Go project in 2023

#28

Post by tester457 »

etxm wrote: post #18
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/…

You’ve gotta check out Charm’s tools for CLI/TUI dev. They are doing some great work. https://charm.sh/

Charm tools I can't live without:

- https://github.com/charmbracelet/wish - Golang SSH server that makes building SSH apps easy

- https://github.com/charmbracelet/vhs - terminal GIF demos

- https://github.com/charmbracelet/log - minimal and colorful go logs

- https://github.com/charmbracelet/gum - leverage charm's bubbles to write useful TUI shell scripts in any language

Re: How to start a Go project in 2023

#29

Post by icholy »

donatj wrote: post #25
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/…

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 like https://github.com/urfave/cli

Re: How to start a Go project in 2023

#30

Post by vardump »

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…

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, but with UPX 10 GB.

Edit: In reality, likely only a fraction of that 100 MB needs actually to be mapped into memory, so without UPX true memory consumption is even less than 100 MB.

Post reply on HN