It works extremely well for language communities that need this, in particular it caught on because you would build something and test it locally and it would work just fine, but then you are running the wrong version of Python or pip installed the wrong version of a library, or you have the wrong version of PHP or Node.js relative to Prod.
For Java and Go, I believe they have already settled these problems, no? You might shell out to other commands and have a weak dependency on your runtime environment that way, but if you stay within your lane, then you already have an executable with all of its dependencies bundled in. They just have a lot less to gain from Docker. I can't see why they would have more to lose.
I mentioned it further down, but my team and I are having preliminary success by integrating with VSCode's "Remote: Docker" extension. They've got it rigged so that all language support can run as remote servers inside the container. They give you a special .json file to control how you'd like to start the image, and you can supply a project-specific dockerfile that takes any additional IDE-specific steps that you want to add in as layers when opening up the project's dev container.
It still has some rough edges - for some reason, you can't supply Build-time arguments to the devcontainer Dockerfile I mentioned above, which makes it hard to get permissions to be non-annoying if you're worried your users will have odd UIDs. And there are a couple other random ticky tack things. But it's by far the closest to actually "developing out of a container" as you and I are imagining it, with all of the attendant benefits. When you want a new dev to start working on the project, they basically do this:
1. git clone newproject 2. Open that project in vscode 3. Respond to a pop-up that yes, I do want to open this in a container 4. <wait for the dev-specific layers to be built> 5. Do a normal project build 6. Enjoy full intellisense, syntax highlighting, import resolution, etc. in exactly the environment that's going to run.
In addition, by including the Dockerfile that builds the base image (the one that the dev container FROM's) into the source, developers can now change library versions and dependencies as a git commit, and then coerce other developers into automatically updating their environments by pushing a new image with a new tag to your gitlab / w/e, and then updating the tag mentioned in the FROM in your .devcontainer/Dockerfile. It's like how you would expect development to feel in 2020.
All the times I can think of when we've run into "works in dev, not in prod" issues that weren't pilot error, it has been down to stuff like firewall configuration or the fact that production is distributed across more nodes than people can realistically simulate on a single dev machine. Never once that I can remember have we had a single production problem caused by the JVM working differently in dev environments.
It is pretty telling that if you're looking online for tutorials about how to effectively use Docker in a development workflow, you will find essentially none that involve running a compiler.