Cool to see that people still find "50 Shades of Go" useful :) If anybody has additional gotchas you want to share I'd love to add them!
How to start a Go project in 2023
141–150 of 205 posts
Re: How to start a Go project in 2023
#142Earlier quoted context omitted.
> Loop variables with closures indeed a brutal footgun but will be fixed soon
Have they actually agreed on how to fix this now?
Effectively yes.
A fix for the loop variable closure problem is now in the official proposal process, which is how language changes happen in Go.
It’s a concrete proposal from the core Go team and seems to be on track for acceptance:
https://github.com/golang/go/issues/60078
An implementation is already available on tip and in the upcoming Go 1.21 release behind a GOEXPERIMENT flag.
The community reaction has been extremely positive. As one approximate measure, an earlier draft of the proposal had 671 upvotes and with 0 downvotes:
Re: How to start a Go project in 2023
#143Earlier 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.
30k servers? Are you operating a botnet?
No.
Re: How to start a Go project in 2023
#144Earlier quoted context omitted.
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.
Answered below. https://news.ycombinator.com/item?id=36052632
Another issue with that is that the systems I was running can go offline at any time. P2P, which could work, kind of wants a lot more uptime than what we had. It would just add some complexity to deal with individual downtime.
Re: How to start a Go project in 2023
#145Things 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/…
Ah, a minimalist
Re: How to start a Go project in 2023
#146How 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…
> the checked in code is impossible to review
While there are valid arguments against vendoring dependencies, I’m not convinced this is one of them in the typical case. It’s exceptionally easy to ignore certain directories when reviewing PRs in GitHub (although I still wish this was available as a repo-level preference), and I’d hope at least this would be the same in Gitlab, BitBucket, etc. I don’t review vendored dependencies, and I wouldn’t expect anyone else to, although the utility of that is admittedly domain-dependent.
Go also has the benefit that its dependencies tend not to be in deep chains, so the level of repo bloat when vendoring is usually not too terrible, at least relatively speaking.
Re: How to start a Go project in 2023
#147How 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 d…
If you have a CI/CD setup, then it makes sense to set up a module proxy that will just cache everything forever.
Re: How to start a Go project in 2023
#148Earlier quoted context omitted.
> - 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?
Not if your default $GOPROXY is google. Google will cache that package indefinitely?
That's explicitly not guaranteed. From https://proxy.golang.org:
> Why did a previously available module become unavailable in the mirror?
>
> proxy.golang.org does not save all modules forever. There are a number of reasons for this…
(I am a googler, but don't work on the go team – my opinions that projects should vendor and actually review their dependencies are my own)
Re: How to start a Go project in 2023
#149I'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.
Could you share some light on how Go became “a bit complicated” ?