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

121–130 of 205 posts

Re: How to start a Go project in 2023

#121

Post by lmm »

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?

Re: How to start a Go project in 2023

#122

Post by lmm »

sureglymop wrote: post #27

Genuine question.. I'll often see Golang pretty heavily criticized here on hacker news. Either that or people say it's a boring language and not worth learning when there is something more interesting (usually referring to Rust or Zig). Why does it have such a bad image? Personally i like it as an alternative for python because: 1. It can build binaries that just work for most architectures quickly. 2. It has nice c-…

Aside from offering nothing new, its design was wilfully, explicitly anti-intellectual. Once you've used an expressive language, having to copy-paste boilerplate becomes very painful. And there's no real USP except Google backing, so it's pretty disappointing to see it beat out better-designed languages.

Re: How to start a Go project in 2023

#123

Post by BreakfastB0b »

jasonwatkinspdx wrote: post #117
sethammons wrote: post #105

Earlier quoted context omitted.

I'm on the vendor bandwagon; always have been. I don't want a github outage to dictate when I can build/deploy. Yes, that happened. That is why we vendor :). Now you can set up a proxy server; however, I don't want to do that. I'm pretty sure I have a few vendored packages that no longer exist at their original import path. For code reviews, we put off checking in the vendor path til the end if possible.

I like vendoring in most languages as it means I can follow all the code flow easily in my editor when debugging something.

I have zero trouble doing that in vscode without vendoring.

Re: How to start a Go project in 2023

#124

Post by za3faran »

liampulles wrote: post #94
maerF0x0 wrote: post #9

I'd add "What's the best web framework?" and answer it with "No." (Go comes batteries included)

And in general, one does not need frameworks in Go to the same degree as say Java or C# - it is an easier language to build things from scratch with I think.

Having worked on a large golang project that did not use any "frameworks", it gets clumsy quickly. There's nothing special in golang that makes it not need a framework.

We ended up moving the project to a DI framework with an ORM-ish library since things got out of hand.

Re: How to start a Go project in 2023

#126

Post by alex_lav »

maerF0x0 wrote: post #9

I'd add "What's the best web framework?" and answer it with "No." (Go comes batteries included)

This is just generally bad advice. The code that gets written as every single project that "doesn't need" web frameworks is just a worse, less secure, more error prone version of the code that comes in every well-supported web framework.

Re: How to start a Go project in 2023

#127

Post by programd »

sethammons wrote: post #105
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…

I'm on the vendor bandwagon; always have been. I don't want a github outage to dictate when I can build/deploy. Yes, that happened. That is why we vendor :). Now you can set up a proxy server; however, I don't want to do that. I'm pretty sure I have a few vendored packages that no longer exist at their original import path. For code reviews, we put off checking in the vendor path til the end if possible.

I have to strongly agree. Third party repos move, code on the internet disappears or silently changes, connectivity goes away at the most awkward time. You always want a point-in-time copy of your code and all dependencies under your control. Sometimes even for legal or security reasons.

Always vendor your dependencies in your private Git repo or a proxy you control. Or heck, even in some long term backup solution if you must. Experience trumps theory.

Re: How to start a Go project in 2023

#128

Post by metaltyphoon »

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?

Not if your default $GOPROXY is google. Google will cache that package indefinitely?

Re: How to start a Go project in 2023

#130

Post by viraptor »

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…

> the checked in code is impossible to review

You're not expected to review the committed dependencies any more than you're expected to review the external repositories every time you update go.mod/sum. If you don't care, just ignore those parts - if you do care, you were already doing it.

Post reply on HN