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

131–140 of 205 posts

Re: How to start a Go project in 2023

#131

Post by bheadmaster »

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

Vendoring dependencies is a nice way of using private Go repositories as dependencies in CI builds without importing any security keys. Vendor everything from dev machine, and build it in CI. You don't even need an internet connection.

Re: How to start a Go project in 2023

#133

Post by latchkey »

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…

Because the 12 GPUS in them are a lot more important than the networking speed. =)

They were for mining ETH... we've turned them off though now that PoS has been successful.

Re: How to start a Go project in 2023

#134

Post by latchkey »

pdmccormick wrote: post #114
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…

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

The complication of implementing BitTorrent isn't worth it at 4mb binary sizes.

Always go with the simplest solution first.

Re: How to start a Go project in 2023

#135

Post by hsn915 »

lmm wrote: post #121
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 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. Go's setup is that if you don't vendor your dependencies then your build might break at any time, no?

No, packages are stored locally in a "modcache".

Unless you're doing something stupid like "create a clean virtual environment for every build" then yea your build might break if you lose the internet or the packages disappear. Just don't ever do that stupid thing.

Re: How to start a Go project in 2023

#136

Post by hsn915 »

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.

30k servers? Are you operating a botnet?

Re: How to start a Go project in 2023

#137

Post by Groxx »

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

Personally I like putting them in the tests, with t.Skip (frequently further in the code, in whatever sets up test dependencies that makes it an "integration" test, so it's automatically skipped).

That way you can blend unit and integration in the same package.

Re: How to start a Go project in 2023

#138

Post by justinclift »

tonyhb wrote: post #111
fsociety wrote: post #101

Earlier quoted context omitted.

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.

That's not totally without cost though, as it can break workflows that cherry pick commits between branches. eg main/master branch vs stable release branches

Re: How to start a Go project in 2023

#139

Post by justinclift »

latchkey wrote: post #133
hnlmorg wrote: post #113

Earlier quoted context omitted.

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…

Because the 12 GPUS in them are a lot more important than the networking speed. =) They were for mining ETH... we've turned them off though now that PoS has been successful.

For large-ish scale distributed updates like that, maybe some kind of P2P type of approach would work well?

IBM used to use a variant of Bittorrent to internally distribute OS images between machines. That was more than a decade ago though, when I was last working with that stuff.

Re: How to start a Go project in 2023

#140

Post by Groxx »

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

Interesting. Though bleh, I would LOVE it if Go would stop releasing things like this with global default values - it leads to tons of libraries not building a way to pass in specific loggers. Better to cut that off at the head.
Post reply on HN