[danny_sf45]

As a developer I prefer using systemd instead of containers to deploy Golang applications.

Without (Docker) containers it is:

- build Go binary and install it in production server

- write and enable the systemd unit file

With (Docker) containers it is:

- write Dockerfile

- install Docker in production server

- build Docker image and deploy container in production server

I get the appealing of containers when one production server is used for multiple applications (e.g., you have a Golang app and a redis cache), but the example above I think containers a bit of an overkill.

[mercora]

i feel the same way, systemd also has some comprehensive sandboxing capabilities built-in.... i have my gripe with systemd too though. mostly with journald because it is slow, likely due to its on disk format, really could have used sqlite for this...

[christophilus]

Same. I deployed a fleet of transcoding servers with the worker logic being a simple Go program. It was super simple with systemd.

[dilyevsky]

Without docker also:

* have a production outage because your libc was updated and now your go apps (which are dynlinked against it by default) won’t start

* mess around with low level cgroup settings if you need to oversubscribe safely

* cry in a corner the second you also need some python libs installed to do some machine learning or opencv or whatever on the side

[Arnavion]

And if you really want to make a container image for any reason, you can still have systemd use that directly as a Portable Service instead of through Docker.