The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)

Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.

Hmm. By that logic, one VM compiles the app and produces or inserts it into another VM runtime environment....?

Basically yes. The dev container is used to build the production container's image.

I like where you're going with that

you're absolutely right, one needs to build images sans all of the dev toolchain and with staging/production flags. but the deps and parts they share in common should be identical. this is a hairy problem to solve, but containers are the solution, mixed with the right pattern, whatever it is. I might not want my dev containers to run on prod, but I want my staging/prod containers to be able to run on my local or whatever environment has the container/orchestration tool.