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

161–170 of 205 posts

Re: How to start a Go project in 2023

#161

Post by bitwize »

xyzzy_plugh wrote: post #153
bitwize wrote: 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…

> There is no magic, we can all be equals in this place.

...in the Harrison Bergeron sense.

The fact that Rust has attracted relatively inexperienced coders to do bare-metal, real-time programming shows that you don't need to nerf the language in order to appeal to interested developers of all skill levels.

Re: How to start a Go project in 2023

#162

Post by ownagefool »

justinclift wrote: post #138
tonyhb wrote: post #111

Earlier quoted context omitted.

Make your git commit history good? `go mod vendor` in a separate commit to your PR changes. Review the commit with local code changes. Easy.

That's not totally without cost though, as it can break workflows that cherry pick commits between branches. eg main/master branch vs stable release branches

I don't think anyone is saying it's without cost, just that there are certain circumstances where you might want to bare the cost.

There's a generic question of how you build confidence in your dependcies not being compromised, and there's steps you can take to mitigate that without reading code, but if everyone was adopting that stance then we'd likely have no mitigations

Re: How to start a Go project in 2023

#164

Post by WA »

0zemp2c wrote: post #32
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-…

HN loves playing "obligatory contrarian" so often commenters will go to lengths to find faults there is nothing wrong with Go; it delivers on its promise, you don't need to be a genius to use it, has good community support, and you can get access to a large and decent job market Rust is a great tool but isn't as purpose-suited to network services as Go Zig is even less purpose-suited to writing network services and w…

If I mostly use TypeScript for the backend, what would be a benefit of Go to make me switch?

Re: How to start a Go project in 2023

#165

Post by TurboHaskal »

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

My favourite languages are Common Lisp and OCaml but I've found Go surprisingly useful professionally. It's easy to onboard new team members, even those without prior experience, and some made contributions the very first day. The language handles complex workloads without much need for tuning or premature optimization and has sensible garbage collection defaults for latency. My main concern is an ongoing trend towards "Java-ification", like watching your favorite punk band start to sound suspiciously like Nickelback, but I think it's still a pretty good language. Go is like one of those "so bad it's good" movies.

Re: How to start a Go project in 2023

#166

Post by nirui »

shepherdjerred wrote: post #119
j3s wrote: 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…

On the other hand, the article contains information about things you are likely to need. This is the exact article I would want to present to someone new to the language. It isn't recommending every tool in existence (well, until you reach the very end) -- it's simply giving information about what you'll almost certainly need to know

> the article contains information about things you are likely to need

Then maybe write something on the specific topic in detail than bundling them into a How-To tutorial. A How-To tutorial is suppose to show "how to" do something correctly, it's a teach than showcase.

I do understand that the author was writing this article with best intentions in their mind, but the resulting article is not a How-To, rather, it's a How-Do-I which is opinionated.

I think when reading articles like this, it is important to remember that, sometimes, more is less.

You import this many tools into your project, many of them are unnecessary and will not help you completing the project, now they've been download and installed, maybe they're even interfering with other tools. You look at them and starts to think "hey, make be I should learn to integrate and utilize them". Then you wasted an afternoon trying to utilize the tool, but by the evening you realized that in order to use the tool correctly, you must restructure your project.

This is not how you can finish things, you know? If you want to write a new project, just `go mod init` it and write the code. And during the writing, if you found the need for some tools, just introduce those tools one by one to fulfill the need. Don't downloading tools or creating "project layouts" just because some tutorial said so.

Re: How to start a Go project in 2023

#167

Post by alecthomas »

jasonthorsness wrote: post #15

I see the note in the article around using -ldflags="-s -w" - is there any other useful tool for binary size analysis/reduction? I was surprised when my binary size doubled when incorporating the K8s client package to get a secret; just using the HTTP secrets API manually without referencing the client package shrank the size by many MB. It would be nice to find similar opportunities for size reduction that aren’t as…

go-binsize-treemap[1] is the best tool for this by a large margin. I came across it because of the exact same reason as you did actually, k8s client bloating my binary massively.

[1] https://github.com/nikolaydubina/go-binsize-treemap

Re: How to start a Go project in 2023

#168

Post by yur3i__ »

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

It is boring, that is the appeal for most of its proponents I think. Obviously that doesn't appeal to the nerdier side of programming, but if your goal is to "write programs" as opposed to "do programming for programmings sake", it gets out of your way most of the time to enable that in my experience.

Re: How to start a Go project in 2023

#169

Post by JetSetIlly »

j3s wrote: 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.

Re: How to start a Go project in 2023

#170

Post by gwd »

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 don't want a github outage to dictate when I can build/deploy. ...I'm pretty sure I have a few vendored packages that no longer exist at their original import path.

Golang now has an automatic transparent caching proxy at pkg.go.dev. If your build has ever worked, it should continue to work even if the original source goes away. Furthermore, your build should only break if both pkg.go.dev goes down, and the upstream source is unavailable (is down or has moved).

Post reply on HN