If you're running 10+ docker containers like my company does, running all of them inside a single VM will use significantly less memory than spinning up multiple VMs like Docker Desktop does.
Nope. You can certainly do that; but “the right way” is to add your sources and compile them (as necessary) during the image build; and then treat the container as an “application”, not as an “environment”. This is how any sane production setup works, and you get a lot of benefits using it during development (such as reproducible builds and only one pre-req for a dev setup: Docker). If you’re just volume-mounting your code into the container, all Docker is providing is a disposable runtime environment. Which is handy for some things, but the general idea is to end up with a fully containerized program that you can tag, push to a registry; and pull to your production environment.
Well sure, but almost nobody is running production workloads on macOS. Regarding development workflows. Won't rebuilding the image every time you make changes be slow? I can get ~1 second reload times for node.js services outside of Docker. And I believe inside Docker too on linux.
It's not necessarily because people are serving their production workloads from macOS systems.
However, they develop on them - and it makes sense to make those environments (and the processes) similar to your actual production setup. So if your applications code gets compiled, and deployed as part of the Docker image - then ideally when you spin up a dev environment, it should follow the same process.
Isn't that the usual case: you have your code on your local filesystem and then run it using an interpreter in the Docker VM?