I have a colleague who insists that that docker is the C++ package manager. I dunno, I've tried to see his point of view but as a usability issue it seems like far too much complexity to just use Docker as a package manager. Compared to something like Cargo for Rust, Docker is incredibly complicated and nags you all the time about installing upgrades. And my understanding is that Docker has non-zero performance impact, right?
Docker performance impact might as well be zero. You're actually using the system kernel, with the application's filesystem (thus dependencies) and other resources (CPU, memory, network access) namespaced away from the rest of the system. So there is no e.g. mapping on top of the extant kernel mapping. I've not noticed and performance impact, though obviously my workflow isn't your workflow.
Seriously, try it. I personally use docker-compose, even for single containers.
Docker is reasonably performant only on Linux. On macOS it's a fat slow VM that bogs down the whole machine (unless you make the VM even slower by giving it fewer CPU cores), has a horrendously slow network file system, and it's managed by a needy Electron app.
And don't forget that all new Macs are now ARM-based, so x86-based Docker images don't work.
My gripe with C is that everyone pretends it's portable, but only care about porting to one (their) platform. It's easy: just use pkg-config/docker/nix. Windows? macOS? Who cares!? Just run a Linux VM!
I always wonder how do people develop in Docker entirely deal with their own shell configuration? Actually install all the tools needed by your .zshrc (or .bashrc) in the container or there is a better solution?
I personally mount a volume and run my normal shell on it. Some operations I do on the container, especially those which relate to deploy (e.g. PHP Composer), but for development the application directory is a normal filesystem directory and I'm using my own VIM and Bash.
Docker is definitely useful, and I have worked with people who have very nice Docker workflows.
Personally, I prefer VMs in GCP, Azure, or AWS. VMs can be stopped when not in use so their use can be inexpensive enough for both hobby projects and work. Instead of writing a Dockerfile, etc. for a new project, I create a VM. This has the advantage of using VMs much more powerful that any laptop I own. This does require being OK with a mosh/ssh, Emacs/Vim, development style.
How do you develop on a VM running on a remote machine? I could make some guesses but I'd love to hear the specifics, especially things that I could adapt into my own workflows. Are you compiling remotely but coding locally?
How is docker a package manager? It may well give you a nice even ground layer to execute your package manager on, but it doesn't do any of the traditional tasks that a language package manager does like e.g. dependency resolution.
You are correct, I skirted a bit around the idea of what a package manager is in response to Nix. Docker does not resolve dependencies, but it does provide a platform in which each application can have its own version of dependencies that won't clobber other things that I'm working on or my system as a whole. Furthermore, the Dockerfile serves as a record (even versioned in git) of the dependencies added for future deploys, like a Composer or NPM lock file would. And that Dockerfile serves additionally as a reference for future projects.
The VM performance hit is far too hard to recommend it for actually running applications. I'll use it to dev for another system (e.g. a Python backend for a web app) but I would not spin up a VM to e.g. compile LibreOffice or -shudder- actually run LibreOffice.
Would it really be an issue to run LibreOffice in a VM on a modern machine? Back in the bad old days of ten years ago, I used to run a Windows 7 VM on my Ubuntu laptop of RAM to watch Netflix. It was pretty tight with 2GB of RAM, but it worked fine.
Seriously, the reproducibility and ability to just share a Dockerfile is amazing, especially with version pinning.