Yeah, I think it may be because it's situation dependent. For me, it always consisted of recompile all binaries and deploy them. And even then, I'm not sure people would enjoy a blog post just telling you to recompile all the things. It's not very sexy, honestly.
In my situation, it wasn't that big of a pain to do so. A lot of these libraries are within stdlib, so a security bug would incur a new release of Go. So an update should be pretty easy.
If's an external library (i.e., one picked up from GitHub for example), it's pretty much the same. Get new source, recompile binary with patched library, ship to all the things.
There are tradeoffs, absolutely. The alternative would be to write something in an interpreted language. That means we need to push a runtime environment up to the node, and that may include managing any libraries that are needed (think Rubygems). Managing these kinds of setups can be a pain, especially if a node has multiple projects with different dependencies. I found that shipping a single binary was often easier for me.
But it goes back to it being an item in the toolbox, depends on what you need and how your systems are built.
The servers dont have internet access and to get files onto them i have to do the same story as above (using sftp). So having 1 static binary that i copy over without having to worry about the dependencies is great.
"TLS/SSL/GZIP/PNG/XML"
all of these are part of the go standard libs, and gets regularry updated with the language.
tls and ssl: https://golang.org/pkg/crypto/tls/ gzip: https://golang.org/pkg/compress/gzip/ png: https://golang.org/pkg/image/png/ xml: https://golang.org/pkg/encoding/xml/
since golang also has built in support for fuzzing in the toolchain, the standard parts are quite battle tested already.
if you study their sourcecode you will also find Benchmark functions, that you can use to benchmark the implementations (go test -bench ./...)
This is something I haven't seen discussed much recently.
Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)?
As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.".
As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found.
[1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein:
http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...