No mention of govuln?!
How to start a Go project in 2023
181–190 of 205 posts
Re: How to start a Go project in 2023
#182Earlier quoted context omitted.
> 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…
Yeah, if you have a problem with it split it into two separate commits to review separately. But WTF is this about not reading your dependencies. Read your dependencies! It is the most amazing superpower for someone to be like “Uh I don't know how Redux handles that and you can just tell them because you have read Redux. And that's also how you'll know, hey, do they have tests, are they doing weird things with monkey…
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?
Re: How to start a Go project in 2023
#183Earlier quoted context omitted.
> - 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?
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.
Re: How to start a Go project in 2023
#184Earlier quoted context omitted.
I used slog for a project a few months ago; then I stopped working on it and continued on it a few weeks ago and there were all sorts of incompatible changes. That's completely fair; it's still in development so this isn't a complaint! But just saying, at this point you need to be prepared to have to deal with that.
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?
Re: How to start a Go project in 2023
#185Re: How to start a Go project in 2023
#186Would love to see this with Erlang/rebar3 or LFE or Gleam or Elixir…
Re: How to start a Go project in 2023
#1871. go mod init.
2. read&write the f*k source code.
nothing else
Re: How to start a Go project in 2023
#188Earlier quoted context omitted.
Yeah, if you have a problem with it split it into two separate commits to review separately. But WTF is this about not reading your dependencies. Read your dependencies! It is the most amazing superpower for someone to be like “Uh I don't know how Redux handles that and you can just tell them because you have read Redux. And that's also how you'll know, hey, do they have tests, are they doing weird things with monkey…
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.
Re: How to start a Go project in 2023
#189Earlier quoted context omitted.
Answered below. https://news.ycombinator.com/item?id=36052632 Another issue with that is that the systems I was running can go offline at any time. P2P, which could work, kind of wants a lot more uptime than what we had. It would just add some complexity to deal with individual downtime.
Interesting stuff. Thanks for the insight
What I ended up with was really neat.
machine cloudflare github
CI would run, build a binary that was stored as an asset in github. Since the project is private, I had to build a proxy in front of it to pass the auth token, so I used CF workers. GH also has limitations on number of downloads, so CF also worked as a proxy to reduce the connections to GH.
I then had another private repo with a json file in it where I could specify CIDR ranges and version numbers. It also went through a similar CF worker path.
Machines regularly/randomly hit a CF worker with their current version and ip address. The worker would grab the json file and then if a new version was needed, in the same response, return the binary (or return a 304 not modified). The binary would download, copy itself into position and then quit. The OS would restart it a minute later.
It worked exceptionally well. With CIDR based ranges, I could release a new version and only update a single machine or every machine. It made testing really easy. The initial install process was just a single line bash/curl to request to get the latest version of the app.
I also had another 'ping' endpoint, where I could send commands to the machine that would be executed by my golang app (running as root). The machine would ping, and the pong response would be some json that I could use to do anything on the machine. I had a postgres database running in GCP and used GPC functions. I stored machine metrics and other individual worker data in there that just needed to be updated every ping. So, I could just update column and the machine would eventually ping, grab the command out of the column and then erase it. It was all eventually consistent and idempotent.
At ~30k workers, we had about 60 requests per second 24/7 and cost us at most about $300 a month total. It worked flawlessly. If anything on the backend went down, the machines would just keep doing their thing.
Re: How to start a Go project in 2023
#190Earlier 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...
How is the implementation of errors "laughable"? An error is just another result of calling a function. Seems reasonable enough.