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

81–90 of 205 posts

Re: How to start a Go project in 2023

#81

Post by nemothekid »

latchkey wrote: post #63
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'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.

If the problem is distribution, what's wrong with gzip? All the upsize of UPX and none of the downsides. If your distribution method is http, then you don't even have to write any code other than setting a Content-Encoding header.

Re: How to start a Go project in 2023

#82

Post by attentive »

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…

also increases startup time

Re: How to start a Go project in 2023

#83

Post by kortex »

shellac wrote: post #50
kortex wrote: post #38

Earlier quoted context omitted.

What's "most modern languages"? Go is better than Python's native tooling (only Poetry and other similar 3rd party tools compare). Javascript I find unruly and fragmented. "Modern" C++ is still a nightmare. Java I haven't touched but I don't exactly hear rave reviews or angry rants about, so I expect it's middling. Rust, scala, and haskell are definitely better experiences, but they are definitely in the minority in…

> What's "most modern languages"? Go is better than Python's native tooling (only Poetry and other similar 3rd party tools compare). Javascript I find unruly and fragmented. Exactly the scale I had in mind, thanks. When I saw 'go get ' rather than dependencies added to the equivalent of a Gemfile / cargo / pom file it had concerns.

There's nothing stopping you from adding to go.mod though, you just have to update the sumfile, no different than using pyproject.toml directly vs adding with CLI.

Re: How to start a Go project in 2023

#84

Post by hintymad »

Any de-facto service framework in Go to recommend, something like Dropwizard but supports both gRPC and HTTP APIs? Such framework should also has ready-to-use integrations things like metrics, logging, tracing and etc. And God please don't just support Prometheus. A pulling-based `/metrics` is really not the best solution, at least not always.

Re: How to start a Go project in 2023

#85

Post by liampulles »

rollulus wrote: post #11

Pretty good article. One comment: it recommends zerolog for logging, but recently slog [1] has started to become part of the standard lib. I guess it’s the future. [1]: https://pkg.go.dev/golang.org/x/exp/slog

I use zerolog at work - I can vouch that it does the job just fine.

Re: How to start a Go project in 2023

#86

Post by liampulles »

hintymad wrote: post #84

Any de-facto service framework in Go to recommend, something like Dropwizard but supports both gRPC and HTTP APIs? Such framework should also has ready-to-use integrations things like metrics, logging, tracing and etc. And God please don't just support Prometheus. A pulling-based `/metrics` is really not the best solution, at least not always.

go-micro is a well known one (though I've never used it): https://github.com/go-micro/go-micro

In my own experience coming from a Java background, I find Go much easier to build from scratch with since the control flow is so plain and the standard library API is simple and well designed - worth trying.

Re: How to start a Go project in 2023

#87

Post by latchkey »

nemothekid wrote: post #81
latchkey wrote: post #63

Earlier quoted context omitted.

> 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.

If the problem is distribution, what's wrong with gzip? All the upsize of UPX and none of the downsides. If your distribution method is http, then you don't even have to write any code other than setting a Content-Encoding header.

gzip doesn't make it small enough.

3mb is after `xz -z -9e`.

But, if you start with something smaller, you generally get something even smaller.

I tried UPX, but ended up with just `-s -w` (and xz), simply because UPX was taking too long to build the binary in CI.

More importantly though, I was responding to OP's absolute.

Re: How to start a Go project in 2023

#89

Post by Karrot_Kream »

cced wrote: post #56
vardump wrote: post #30

Earlier 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?

I'm curious, was the practice of using upx there before you got there? We generally A/B test changes like this pretty thoroughly by running load tests against our traffic and looking at things like CPU and Memory pressure in our deploys.

Re: How to start a Go project in 2023

#90

Post by liampulles »

kortex wrote: post #44

I 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.

I use Makefiles for my projects, and right at the top I do:

GOBIN := $(shell go env GOBIN)

And then use that var where needed.

Post reply on HN