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

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