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

111–120 of 205 posts

Re: How to start a Go project in 2023

#111

Post by tonyhb »

fsociety wrote: post #101
ownagefool wrote: post #98

Earlier quoted context omitted.

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.

Make your git commit history good? `go mod vendor` in a separate commit to your PR changes. Review the commit with local code changes. Easy.

Re: How to start a Go project in 2023

#112

Post by djbusby »

sethammons wrote: post #105
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.

I do all my vendor in a "cache-proxy" thing (for lots of vendors). That box always runs, I just need upstream the first time I get the package. Doesn't bloat my code, makes sure package is available and makes audits of vendor stuff easy.

Re: How to start a Go project in 2023

#113

Post by hnlmorg »

latchkey wrote: post #91
Thaxll wrote: post #66

Earlier quoted context omitted.

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

I’m curious why you’ve got servers on 100Mb. Last time I ran a server on 100Mb was more than 20 years ago. I remember the experience well because we needed AppleTalk support which wasn’t trivial on GbE (for reasons unrelated to GbE — but that’s another topic entirely).

What’s your use case for having machines on 100Mb? Are you using GbE hardware but dropping down to 100Mb, and if not, where are you getting the hardware from?

Sounds like you might work in a really interesting domain :)

Re: How to start a Go project in 2023

#114

Post by pdmccormick »

latchkey wrote: post #91
Thaxll wrote: post #66

Earlier quoted context omitted.

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

Sounds like an interesting problem to have. Would something peer-to-peer like BitTorrent work to spread the load? Utilize more of the networks' bisectional bandwidth, as opposed to just saturating a smaller number of server uplinks. I recall reading many years ago that Facebook did this (I think it was them?)

Re: How to start a Go project in 2023

#115

Post by pdmccormick »

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…

A Go vendoring pattern that I've found very useful is to use two repositories, the first for the main "project" repository, then a second "vendoring" repository that imports the first as a module, and also vendors everything.

This may require a few extra tricks to plumb through, for example, to make all cmd's be externally importable (i.e. in the project repository, transform "cmd/foo/%.go" from being an unimportable "package main" into an importable "cmd/foo/cmdfoo/%.go", then have a parallel "cmd/foo/main.go" in the vendoring repository that is just "func main() { cmdfoo.Main() }", same as you have in the project repository in fact).

Vendoring aside, this is also a useful pattern if you're "go:embed"ing a collection of build artefacts coming from another source, like a frontend HTML/JS/CSS project.

Re: How to start a Go project in 2023

#116

Post by mikepurvis »

themerone wrote: post #68
cced wrote: post #56

Earlier quoted context omitted.

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.

Also impacts startup time. Really it's only appropriate for situations like games where you're very confident there will be just one instance of it, and it'll be long-running.

And even then, it's of dubious value when game install footprints are overwhelmingly dominated by assets rather than executable code.

Re: How to start a Go project in 2023

#117

Post by jasonwatkinspdx »

sethammons wrote: post #105
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.

I like vendoring in most languages as it means I can follow all the code flow easily in my editor when debugging something.

Re: How to start a Go project in 2023

#118

Post by mikepurvis »

hnlmorg wrote: post #113
latchkey wrote: post #91

Earlier quoted context omitted.

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

I’m curious why you’ve got servers on 100Mb. Last time I ran a server on 100Mb was more than 20 years ago. I remember the experience well because we needed AppleTalk support which wasn’t trivial on GbE (for reasons unrelated to GbE — but that’s another topic entirely). What’s your use case for having machines on 100Mb? Are you using GbE hardware but dropping down to 100Mb, and if not, where are you getting the hardwa…

Not the GP but edge devices on wifi/m2m are another scenario where you're very sensitive to deployment size.

Which can also be solved with compression at various other stages of the pipeline as mentioned by other commenters, but just to say that that's an easy case where this matters.

Re: How to start a Go project in 2023

#119

Post by shepherdjerred »

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…

On the other hand, the article contains information about things you are likely to need. This is the exact article I would want to present to someone new to the language. It isn't recommending every tool in existence (well, until you reach the very end) -- it's simply giving information about what you'll almost certainly need to know

Re: How to start a Go project in 2023

#120

Post by SPascareli13 »

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

I made this mistake in a project at work...never again.
Post reply on HN