Earlier quoted context omitted.
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.
How to start a Go project in 2023
171–180 of 205 posts
Re: How to start a Go project in 2023
#172well written post! one minor thing: I've skipped using build tags for integration tests because those tests will be out of sync one day with your main code, even with Goland (?). Instead I use the usual test and check if an environment variable is set, if not, then t.Skipf("env var %q not set, skipping integration test",envVarName) or you can use an additional CLI flag, e.g. in `feature_test.go` write func init() { f…
Re: How to start a Go project in 2023
#173Earlier 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. 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
#174Please 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)…
Re: How to start a Go project in 2023
#175Re: How to start a Go project in 2023
#176Earlier quoted context omitted.
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)
If you're vendoring something without an appropriate license, you're skating on thin ice legally.
Re: How to start a Go project in 2023
#177Earlier quoted context omitted.
Yeah, it's pretty much optimized for junior programmers to write babby's first enterprise network service in. It's got a lot of features junior programmers think are nice and easy to work with, but as you mature as a developer its verbosity becomes annoying and its shortcomings become apparent. Using Go as a PHP alternative is pretty much the use case most aligned with its niche. So go nuts if you like doing that. Bu…
The post I'm replying to is downvoted and I should probably simply move on but there's key phrasing here I'd like to point out: > optimized for junior programmers to write babby's first enterprise This is the (toxic) attitude Go strives to distance itself from. There is no magic, we can all be equals in this place. It's humbling. I'm not aware of any other mainstream project that captures this essence so well. There…
Re: How to start a Go project in 2023
#178i 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…
That used to be how you started a go project. Unfortunately, modern Go requires you to first setup a go.mod file with: go mod init Still simple but for better or worse it's now a necessary part of the process.
go run main.go
So no need to init a package if you are just using the stdlib and you’re in a hurry.Re: How to start a Go project in 2023
#179How 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 d…
But WTF is this about not reading your dependencies. Read your dependencies! It is the most amazing superpower for someone to be like “Uh I don't know how Redux handles that and you can just tell them because you have read Redux. And that's also how you'll know, hey, do they have tests, are they doing weird things with monkeypatching classes or binaries at runtime, “oh the request is lazy—it doesn't get sent unless you attach a listener to hear the response,” what would it look like for the debugger to step through their code and is that reasonable for me to do or will I end up 50 layers deep into the call stack before the code actually does the thing.
I get it, this dependency is 100,000 LOC and if you printed it out that's basically 5 textbooks of code, you'd need a year to read all of that and truly understand it... Well don't use that dependency! “But I need it for dependency injection...” I mean if that's all then use a lightweight one or roll a quick solution in a day or explicitly inject your dependencies in 5 pages or or or. My point is just that you have so many options. If that thing is coming at 5 or 50 textbooks or whatever it is, what it actually means is that you are pulling in something with a huge number of bells and whistles and you plan on using 0.1% of them.
Re: How to start a Go project in 2023
#180Earlier quoted context omitted.
That used to be how you started a go project. Unfortunately, modern Go requires you to first setup a go.mod file with: go mod init Still simple but for better or worse it's now a necessary part of the process.
You can still do go run main.go So no need to init a package if you are just using the stdlib and you’re in a hurry.