But on that note, the fact that there isn't a single cross-platform filesystem that works on Windows, MacOS, and Linux has been one of the greatest detractors for a docker-based development environment. The performance of Docker for Mac is often a showstopper for running a big app in docker for development, especially in combination with other slow and i/o heavy tools like webpack.
Apparently Apple came very close to using ZFS too, instead of building APFS. Oh what could have been.
The performance of the fs is not really related to the container fs (apfs seems like it could be great for a container fs, in theory), but rather the fs being shared across the VM barrier which enables sharing developer-local files with the container.
Since you were able to describe the problem of fs-sharing-for-containers so well, I was wondering if you have any recommendations for a usable cross-platform dev workflow?
We're currently using a mix of docker-compose for the service and native development for the main application (requiring separate instructions for win, mac, and linux). I'd love to be able to transition this to a simpler all-docker-compose setup.
I fought with this regularly for about a year - on Windows - and recently settled on duplicating almost everything inside the VM and outside it, except the bare shared code I'm working on.
Okay, that sounds confusing, I know. We use Vagrant, because you can put every kind of ancient incantations into the Vagrantfile to check for whatever misconfiguration on the host, and so on. Plus you don't have to wrap your app in Docker this way, so debugging becomes a bit easier.
Basically we have a fair bit of Ruby in the Vagrantfile setting up a dev env on the host (scoop + pip + poetry) and provision files setting up the env inside the VM. (Let's say a DB + pip + poetry + uWSGI.) This is necessary, because for code completion you want the dependencies accessible for your IDE. (Yes, PyCharm Ultimate Pro Gold Edition has a way to use remote interpreters, but then you need to guarantee that for every dev too, and it's still not as fast as just having the files on the host in a venv.)
The VBoxSF shared filesystem has a lot of quirks, so we minimize the shared stuff. (We tried NFS and CIFS/SMB too. Both were amazing disasters.)
For NodeJS stuff we only have the runtime dependencies in the VM (database, other backed services), but you have to be careful to script everything in a cross-platform way in package.json (so basically don't script anything there start the NodeJS process as soon as you can, and work inside that).
And the provision scripts are simple, because they just setup docker containers. Usually without compose, because meh, it's easier to just type a few lines of Bash to rm -f the container and run a new one, and maintaining a useful compose file is unnecessary at that point.
Apparently Apple came very close to using ZFS too, instead of building APFS. Oh what could have been.