51–60 of 90 posts
Add -ldflags '-s -w' to go build to strip DWARF, symbol table and debug info. See also: -trimpath
I mean sure, in theory you shouldn't get any of those in production, but no software is perfect.
Earlier quoted context omitted.
Ease of deployment?
Seems more difficult. Without Docker I don't have to bother with a new technology, use new commands and learn new syntax.
If that works for you, then there's no need to change. But if you ever end up in an environment where multiple different applications are deployed, or if your app needs to be deployed a thousand times, that's where e.g. Docker may come in handy.
I'm currently being forced to use Docker against my will, with exactly this setup. The CGO overhead every time the container is built is absurd, making developemnt and testing painful. I habe to try this article out, but it doesn't seem like it solves the problem. Does anyone have advice how to solve this without too much Docker magic?
Earlier quoted context omitted.
Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...
> you first need to handle the complexities of Docker The complexity of Docker is not that big for a Go deployment though, especially if you have all the other bits for orchestrating your Docker containers (for the rest of your stack) already in place. You mostly just copy the binary into a slim image and you are done.
Earlier quoted context omitted.
Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc
> Docker has a pretty terrible deployment story (...) This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments. It even shines as a stand-alone barebones clustering solution with Docker swarm mode.
Our backend teams rarely do anything with containers, but all apps deploy to K8s (platform team manages).
We deploy SQLite… don’t remember any Cgo requirements, however we’re also deploying each SQLite “instance”, or db-files, to a node directly, and for low data gravity on SSDs. Go interacts with database/sql.
> C libraries are required to interact with SQLite Or: modernc.org/sqlite (plus https://github.com/zombiezen/go-sqlite ), "an automatically generated translation of the original C source code of SQLite into Go" as mentioned yesterday: https://news.ycombinator.com/item?id=29959193#29960726
Earlier quoted context omitted.
Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).
Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...
Docker does this quite well, and solves a bunch of other problems you're likely to have regardless. One really simple example is "how do you copy it to the server?" Do you have ssh keys for your server on development machines? How do you handle the "Oh I'll just remote in and fix this one X"?
It's also _crazily_ easy to get started with, and handle middling amounts of scale. If you're on AWS, Elastic Beanstalk is plug and play. If you're not, DigitalOcean App platform will host it for you, with automated deployments from git for $5/month with basically no configuration needed from you.
I'm currently being forced to use Docker against my will, with exactly this setup. The CGO overhead every time the container is built is absurd, making developemnt and testing painful. I habe to try this article out, but it doesn't seem like it solves the problem. Does anyone have advice how to solve this without too much Docker magic?
Why are you forced? We rarely touch docker any more, even though our prod apps run on K8s.