5 ms·
I've said this before here but I think the ability of Go to create a server as a single statically linked binary is a HUGE deployment advantage. It's so much ea
by cageface 15y ago
I've said this before here but I think the ability of Go to create a server as a single statically linked binary is a HUGE deployment advantage. It's so much easier to just compile exactly what you want and push out a single file.
- hynek 15y agoDoes it also help with deployment of non-code related files (eg. static files in web apps)?
- cageface 15y agoNo but I think the dependencies among those files tends to be less intricate and brittle than code.
- hynek 15y agoIt’s not necessarily about dependencies but about having one self-contained file (= deb/rpm) that can be deployed easily. The idea about doing this kindled when we started deploying Django apps – you can see in the second example that it’s rather intricate. The dependencies are just a matter of `pip install -r requirements.txt`.
- nakkiel 15y agoDefinitely a problem in Go. It's still possible to embed resources in the binary but if you're talking about a lot of such resources, the resulting binary size can be an issue as well. Not to mention resources won't be available outside of the binary.
- stock_toaster 15y agoI don't think it is any more of a problem with Go than any statically compiled C/C++ binary. You would still want to use chef, puppet, or some home rolled package deployment toolchain, if for no other reason than being able to ensure a consistent state and bring up new nodes quickly.