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

71–80 of 205 posts

Re: How to start a Go project in 2023

#71

Post by shakow »

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…

> but isn't as purpose-suited to network services as Go

Why?

Re: How to start a Go project in 2023

#72

Post by syngrog66 »

just start writing some Golang. same as any other programming language for decades now.

Really thats all you need to get started. OK: a text editor, the Golang toolchain and ideally a terminal/shell.

Worry about other things if/when they come up, right in your face. Assume by default: YAGNI.

Re: How to start a Go project in 2023

#73

Post by sureglymop »

hombre_fatal wrote: post #59
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-…

> But it overall seems much nicer than running node/js or python on the server side, no? No, it's just trade-offs. I think you are making the same mistake by looking for validation on HN that you're making some sort of Better Choice, but you're just making a normal choice. You just don't yet have the experience to see all the trade-offs nor how they compare to, say, Node or Python. For example, there are various ways…

But I'm not really making a choice. I'm open to anything, i don't want to restrict myself. I have and do use the things i mentioned a lot (node/python). I was just curious what the people have to say since i noticed this recently. I don't really need the validation since I'll try out all available options due to curiosity anyway.

Re: How to start a Go project in 2023

#74

Post by sapiogram »

0zemp2c wrote: post #35
gadflyinyoureye wrote: post #31

Earlier quoted context omitted.

It’s verbose. Errors everywhere. There are a lot of foot guns. nil slice? Fine. nil map? Segfault. Loop variables with closures. The list goes on. Generics seemingly split the community. May be some libraries won’t get used because they picked the wrong side. It’s surprisingly weak at modeling data. Union types would really help out. The community is so anti-design that it’s hard to play with them. Most want to make…

> Loop variables with closures indeed a brutal footgun but will be fixed soon

Have they actually agreed on how to fix this now?

Re: How to start a Go project in 2023

#75

Post by Paul-Craft »

0zemp2c wrote: post #39
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 is a bit of project smell, but for large teams it removes the confusion of who has what version of a dependency unfortunately most teams don't schedule a periodic `go mod tidy` so you just end up with ancient deps most people never read the code of the deps they pull in, so I don't think vendoring provides any security assurances

I'd go way farther than "a bit of a project smell." I literally cannot think of a single instance in which vendoring a dependency for any reason other than, say, caching it for CI so you don't have to worry that the maintainer pulls a `left-pad` on you, has gone well.

If the package has bugs, you're far better off either waiting for upstream fixes, working around the bug in your application code, or just switching to a different library. That goes double if the library you're using is missing a feature you need, even if it's scheduled for the next version release.

Unless you're prepared to maintain a full-on fork of the dependency (and, if you do, please make it public), everything about vendoring for these reasons is 100% bad for you for very little incremental benefit. It's like the joke about regular expressions ("You have a problem and think 'I'll use regexes to solve it.' Now you have two problems"), except it's not a joke, and it sucks way more.

TL;DR: Vendoring to cache for CI/build servers, yes. Any other reason, just don't; it's not worth the headaches.

Re: How to start a Go project in 2023

#76

Post by sapiogram »

shakow wrote: post #71
0zemp2c wrote: post #32

Earlier quoted context omitted.

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…

> but isn't as purpose-suited to network services as Go Why?

+1. In terms of development speed, Node + Axios is lightyears ahead. It's like 5 lines of code to send a JSON payload via http, vs 15+ in Go. The Javascript version is much likely to be correct as well, since it doesn't let you forget to check any of the three errors, or forget to check the http status of the response.

Re: How to start a Go project in 2023

#77

Post by ashishb »

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.

Any source that you can cite for this? I'm not saying you are wrong. I'm just curious to see more proof of this.

Re: How to start a Go project in 2023

#78

Post by vardump »

cced wrote: post #56
vardump wrote: post #30

Earlier quoted context omitted.

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…

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?

Normally operating system simply maps binaries, executables and loadable libraries (.dylib, .so, .dll, etc.) into memory. The cost is approximately same whether you do this once or 1000 times. The code is executed from the mapped area as-is.

However, when a binary is compressed, this cannot work, because in the file the binary is represented as a compressed data. The only way you can work around is to allocate some memory, decompress the binary there, map the region as executable and run it from there. This results a non-shareable copy of the data for each running instance.

A random link about this issue in practice: https://github.com/nushell/nushell/issues/4131

Re: How to start a Go project in 2023

#79

Post by agotterer »

athorax wrote: post #2

The article mentions GOW[0] for a file watcher. If anyone is looking for a non-go specific one, I've really enjoyed reflex[1]. Makes it super easy to reload different parts of a project based on what type of file has changed. [0] https://github.com/mitranim/gow [1] https://github.com/cespare/reflex

I’ve been very happy with Air - https://github.com/cosmtrek/air

Re: How to start a Go project in 2023

#80

Post by themerone »

ashishb wrote: post #77
themerone wrote: post #68

Earlier quoted context omitted.

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.

Any source that you can cite for this? I'm not saying you are wrong. I'm just curious to see more proof of this.

https://stackoverflow.com/questions/9219244/why-does-my-appl...
Post reply on HN