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

91–100 of 205 posts

Re: How to start a Go project in 2023

#91

Post by latchkey »

Thaxll wrote: post #66
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.

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.

The servers are not all on gige. Many are on 100mbit and yes, that saturates the network when they are all updating. I learned through trial and error.

The updates are not pushed, they are pulled. Why? Because the machines might be in some sort of rebooting state at any point. So trying to first communicate with the machine and timeouts from that, would just screw everything up.

So, the machines check for an update on a somewhat random schedule and then update if they need to. This means that a lot of them updating at the same time would also saturate the network.

Smaller binaries matter.

Re: How to start a Go project in 2023

#92

Post by liampulles »

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

It is a boring, no-magic language on purpose.

I think it appeals to cynical devs who have seen projects misuse more powerful languages, and who don't want to debate style guidelines or linter settings for any more than 5 minutes. I count myself among them.

Re: How to start a Go project in 2023

#93

Post by liampulles »

jasonthorsness wrote: post #15

I see the note in the article around using -ldflags="-s -w" - is there any other useful tool for binary size analysis/reduction? I was surprised when my binary size doubled when incorporating the K8s client package to get a secret; just using the HTTP secrets API manually without referencing the client package shrank the size by many MB. It would be nice to find similar opportunities for size reduction that aren’t as…

The go k8s packages are pretty bloated - this may also just be a niche case. If you are looking to get secrets with hot reloading, you might also consider mounting a file or setting env vars and coupling it with this reloading operator: https://github.com/stakater/Reloader

Re: How to start a Go project in 2023

#94

Post by liampulles »

maerF0x0 wrote: post #9

I'd add "What's the best web framework?" and answer it with "No." (Go comes batteries included)

And in general, one does not need frameworks in Go to the same degree as say Java or C# - it is an easier language to build things from scratch with I think.

Re: How to start a Go project in 2023

#95

Post by j3s »

i don't like this post because it makes golang feel overwhelming when the stdlib + default tooling is plenty good for most use-cases. it's as if someone made a post called "how to go hiking in 2023" and spent 10 pages linking to gear on amazon.

how should you actually start hiking? grab a water bottle, get outside, and hike.

here is how you should _actually_ start a go project in 2023:

    $EDITOR main.go
    go run .
everything else you should add as needed. don't overcomplicate things.

Re: How to start a Go project in 2023

#96

Post by xh-dude »

arp242 wrote: post #57
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 used slog for a project a few months ago; then I stopped working on it and continued on it a few weeks ago and there were all sorts of incompatible changes. That's completely fair; it's still in development so this isn't a complaint! But just saying, at this point you need to be prepared to have to deal with that.

FWIW: slog has been pretty stable for a month or two, and should be officially standard library in go1.21

There was a last round of changes mostly revisiting use of contexts a few months ago - hats off to jba for taking a lot of time to work out the best fit

Re: How to start a Go project in 2023

#97

Post by opportune »

j3s wrote: post #95

i don't like this post because it makes golang feel overwhelming when the stdlib + default tooling is plenty good for most use-cases. it's as if someone made a post called "how to go hiking in 2023" and spent 10 pages linking to gear on amazon. how should you actually start hiking? grab a water bottle, get outside, and hike. here is how you should _actually_ start a go project in 2023: $EDITOR main.go go run . everyt…

Yeah, for a basic Go service or tool I don’t think you usually need anything besides the standard lib. Maybe you will want to use a client library but most of the time it’s only thinly wrapping various http functionality. I work on some go binaries used at massive scale that have little/no dependencies.

Re: How to start a Go project in 2023

#98

Post by ownagefool »

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.

Re: How to start a Go project in 2023

#99

Post by baby »

I've left Golang for a while, then when I came back it felt a bit complicated to figure out how to get started. I feel rustup.rs, really got Rust to a much better spot than Golang in such a short amount of time.

Re: How to start a Go project in 2023

#100

Post by ownagefool »

Paul-Craft wrote: post #75
0zemp2c wrote: post #39

Earlier quoted context omitted.

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

I'd go way farther than "a bit of a project smell." I literally cannot think of a single instance in which vendoring a dependency for any reason other than, say, caching it for CI so you don't have to worry that the maintainer pulls a `left-pad` on you, has gone well. If the package has bugs, you're far better off either waiting for upstream fixes, working around the bug in your application code, or just switching to…

If you work on code that introduces threat to life, you might be prepared to own all the code, even if you don't write it all from scratch.
Post reply on HN