Live data from Hacker News

How to start a Go project in 2023

boyter.org

171–180 of 205 posts

Re: How to start a Go project in 2023

#171

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.

Interesting stuff. Thanks for the insight

Re: How to start a Go project in 2023

#172
post #5

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

additionally, if it's an integration test, you may want to always run with `-count=1` at least. e.g. if you use a DB, you certainly want to not skip any cached tests when the schema changes, etc.

Re: How to start a Go project in 2023

#173

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

Sure, it makes sense. But that's another moving part in the machinery that you have to configure and maintain. It also makes sense to just keep things simple and vendor dependencies, sacrificing some extra space for simplicity of configuration. It just depends on what tradeoff you're looking for.

Re: How to start a Go project in 2023

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

Well, you can configure your editor to lint your test files with build tags and that's the end of the issue. At least on VSCode and Goland you can. I think it's way cleaner to have your integration tests with a build tag rather than this extra piece of code. If you don't have tests all over the place and you are moderately organized with your folder structure, there is no reason why build tags should represent a discoverability issue.

Re: How to start a Go project in 2023

#176

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

> proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license.

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

#177
post #52

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

I'm tired of people saying that there is no magic. How are you saying that? Do you any basis? Named returns, compiler not ensuring that non pointer receivers do not modify a property, bare bones dependency management, laughable implementation of errors, the list goes on...

Re: How to start a Go project in 2023

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

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.

Re: How to start a Go project in 2023

#179
post #146
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…

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

Yeah, if you have a problem with it split it into two separate commits to review separately.

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

#180
post #178

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

I didn't know that. That's genuinely useful to know.
Post reply on HN