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

191–200 of 205 posts

Re: How to start a Go project in 2023

#191

Post by liggitt »

gwd wrote: post #176
liggitt wrote: post #148

Earlier quoted context omitted.

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.

That's just one possible reason. The disclaimer does not specify all the possible reasons the proxy would drop a saved version. Treating it more like a cache seems appropriate.

Re: How to start a Go project in 2023

#193

Post by kubanczyk »

lmm wrote: post #122
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.

> it beat out better-designed languages

Which languages did Go beat out?

Re: How to start a Go project in 2023

#194

Post by foobiekr »

vardump wrote: post #30
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…

UPX only means smaller files on the disk, but it comes with a cost: it tends to increase memory requirements, because the binary on the disk cannot be mapped to memory anymore. Unless it's uncompressed somewhere in the filesystem. Worse, if you run multiple instances of the same binary, none of them can be shared. A bit simplified, without UPX, 100 processes of 100 MB binaries requires only 100 MB RAM for the code, b…

All true, but I think a compressed iso9660fs can actually support dynamic paging - the pages are decompressed into memory, obviously, but can be demand paged without staging them to media.

Re: How to start a Go project in 2023

#195

Post by foobiekr »

themerone wrote: post #68
cced wrote: post #56

Earlier quoted context omitted.

Can you expand on this a bit? I use upx at work to ship binaries. Are you saying these binaries have different memory usage upx’d than they do otherwise?

Every instance of a program will use an amount of ram equal to the uncompressed size. If the application is uncompressed, the uncompressed executable will be loaded into ram 1 time and be reused by every instance of the application.

Containers really bust this model.

Re: How to start a Go project in 2023

#196

Post by foobiekr »

pdmccormick wrote: post #115
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…

A Go vendoring pattern that I've found very useful is to use two repositories, the first for the main "project" repository, then a second "vendoring" repository that imports the first as a module, and also vendors everything. This may require a few extra tricks to plumb through, for example, to make all cmd's be externally importable (i.e. in the project repository, transform "cmd/foo/%.go" from being an unimportable…

At this point, why not do the clean thing and have a forked repo per dependency. Setting up your "monorepo" like construct is as easy as a gitignore and a json file listing your dependencies and the specific hash, then have a script pull them and do a checkout.

This lifecycle is vastly cleaner and easier to update/control than vendoring, and also forces you to actually have explicit copies of everything your build needs in the same way that vendoring does, but in a cleaner, separated, traceable, manageable way.

Re: How to start a Go project in 2023

#197

Post by lmm »

kubanczyk wrote: post #193
lmm wrote: post #122

Earlier quoted context omitted.

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.

> it beat out better-designed languages Which languages did Go beat out?

I didn't mean globally (though on a quick search I'm seeing it place above e.g. Swift, Kotlin, Dart, and Ruby), I meant it's frustrating to see Go be chosen over a better-designed language "in the small", for a specific product or SDK.

Re: How to start a Go project in 2023

#198

Post by xyzzy_plugh »

bitwize wrote: post #161
xyzzy_plugh wrote: post #153

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…

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

Who said anything about attracting inexperienced developers? If anything I'd argue that's a negative for a healthy ecosystem, and I'd argue it has been a negative for Rust.

It's the junior engineers that most often struggle with trying to devise a way to use every language feature under the sun when solving a problem, not the other way around.

Re: How to start a Go project in 2023

#199

Post by gjadi »

crdrost wrote: post #188
gjadi wrote: post #182

Earlier quoted context omitted.

In this context, what would be useful is something like a linker-pruning at the source level. That is, when your code is compiled, the linker can prune code that is never called. Then a feedback mechanism could show which part of the code is actually used (like looking in the .map of the linker). Does something like that exist?

Google's Closure compiler was doing this for JavaScript, where it matters because network bandwidth is a limited resource in some places. There it was called “tree shaking” if you want the jargon name for it.

Thanks!

Re: How to start a Go project in 2023

#200

Post by lima »

ovao wrote: post #146
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 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 then it's trivial to sneak a backdoor past code review.
Post reply on HN