Live data from Hacker News

How to start a Go project in 2023

boyter.org

201–205 of 205 posts

Re: How to start a Go project in 2023

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

The mistake of using build tags, or the mistake of not using them?

Re: How to start a Go project in 2023

#202
post #183
post #135

Earlier quoted context omitted.

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.

This is essentially he default when using most CI services, however.

Hence most CI services are stupid

Re: How to start a Go project in 2023

#203
post #184
post #96

Earlier quoted context omitted.

FWIW: slog has been pretty stable for a month or two, and should be officially standard library in go1.21 There was a last round of changes mostly revisiting use of contexts a few months ago - hats off to jba for taking a lot of time to work out the best fit

Where do you keep up to date on what will be included in future releases?

A few places I look: - https://dev.golang.org/release#Go1.21 - might be the same info as https://github.com/golang/go/milestone/279 in a different form

and here is a link to the draft release notes https://tip.golang.org/doc/go1.21

Re: How to start a Go project in 2023

#205
post #177

Earlier quoted context omitted.

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

None of that qualifies as magic. Indicators of magic features are implicitness, action-at-a-distance, high complexity.
Post reply on HN