There are a lot more problems than you think with letting users have arbitrary code execution. And no, Docker is not an acceptable security solution for this, since it's most certainly possible to break out of containers. Even if you're using a dedicated VM, this is not a good idea. And from a brief look at glot-code-runner, it doesn't seem like there's even that much built in to protect against various forms of use.
A more sane design would be to use something like emscripten to enable all these different languages to run in the browser.
"Docker is not an acceptable security solution for this, since it's most certainly possible to break out of containers."
Could you point to some resources that show that it is possible to break out of Docker containers? I understand that there have been bugs in the past that have caused this (using that to conclude that glot.io shouldn't use Docker is a bit like saying OpenSSL is now useless because of heartbleed) but it seems unlikely that breaking out of containers is possible due to the way Docker is designed.
Most of the vulnerabilities you mention are actually kernel vulnerabilities. While they affect Docker, they more accurately affect everything that uses "Linux containers". Although, Docker did have a bad history of security bugs with symlinks.
But given the fact that Linux doesn't have real containers, I feel very conflicted about opening that up to the internet.
We built something like this for our our data science platform (https://civisanalytics.com/products/end-to-end-data-science/), but the containers run on a group of workers that are isolated in one VPC per customer. And even that is for enterprise customers where you have some layer of accountability - I can't imagine opening it up to the wild internet.
A more sane design would be to use something like emscripten to enable all these different languages to run in the browser.