Developer Environments are a complex system to maintain. First, you need to consider a few options:
There are other things to consider, but using the examples above, let's discuss a few paths that can be taken.
Local environments provide the greatest flexibility for your developers. They can use whatever editor they want - VSCode, Sublime, Vim, Emacs, etc. They can manipulate and manage their own system however they want as well. These are great benefits, but also problems to overcome.
When anyone can change anything on their system, you essentially end up being an operations team for n servers, with n configurations. Due to this, it becomes very difficult to maintain and ensure proper functioning. This is why many team reach to remote solutions.
Remote solutions can be truly remote (in the cloud) or they could remain on your laptop. Something like Docker can provide a contained system that you fully control, in which the applications run. Docker Compose or Kubernetes have often been chosen for people to manage these instances.
This solution seems like a great one - full, maintainable control. However, editors have a big problem with this. As the docker container / Kubernetes pod is not "local", there needs to be some sort of network drive / synced drive to enable developers to use their own editors of choice. This introduces a sync problem that can be very problematic for developers - where is the source of truth? In true remote solutions, latency becomes a concern as does the fact that you've introduces an "always online" dependency that doesn't play nicely with remote employees, people in transport, or people working from home.
Many developers have an operating system of choice - one they're most familiar with - and you may want to support that. With this in mind, dependency management becomes a concern that should be addressed and it differs based on operating system. See Dependency Management, for more information.
Another good issue to address is operating system dependencies.
Which language you choose to support makes little difference. Each has a build system, each has a dependency manager, etc.
When you choose multiple, or have multiple needed for an app, then you start to have some slowdowns and must support multiple versions of the same type of tool at once.
As long as each tool can support automation in some form (e.g. bundle install and bundle check for Ruby), then you can build off of it without any problems. The issue may be getting people to use the same toolchain (e.g. glide vs goget for golang, or pyenv vs virtualenv for Python).