I never understood those people saying that the setup is more complicated. It's always the exact same setup you'd make locally, but you script it in a Dockerfile so that it can be shared across developers in the project so that environment parity is ensured. Your container can inherit production (or the other way around, depending on what you're trying to achieve).
For my PHP projects, I never had issues with changes in real time when using docker-compose. The setup is simple: base php image + extensions (and some optimizations) for prod, prod image is inherited by a dev image (xdebug and whatnot). Since I work across several projects (and advise on some), I am daily switching envinronments.
A simple "docker-compose up -d" and I have project A (with php7.1, mySQL and whatever). 10 minutes later I may be on project B (with php7.3, MariaDB, Rabbit and whatnot). Doing the same in a local environment? Are you kidding?
And for Golang, I don't build containers. I have containers for some dependencies, using local ports, but then I build locally ( still using Docker though, basic alpine image with Go and simply build for Darwin architecture).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.