Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well.
As to interpreted languages, JS/V8 has probably seen more optimization than any other interpreted language. As to Java, you don't need a 400-500mb base image either. Rust takes much longer to develop against, as does erlang even if you're familiar with it. If you're parsing JSON into concrete objects, the overhead is often larger with compiled languages than interpreted, where JS just works. I can generally get stuff working in around 1/8 the time it takes for peers to use a compiled language to do the same.
Go is probably a better option than the three you suggested, even then more often than not, I would choose node, just because of the flexibility I get with npm and the larger community. If I, in turn need to eek more performance, or have a process that requires more compute per request, then I'll often reach for another language and/or even choose a Function as a Service wrapper.
Why not C++17 in combination with h2o? I don't know why the compilation step is an issue if compilation and linking takes less than a second which is less time than switching back to the browser. I can pass around lambdas with ease and my lines and functions have become much more succinct with the newer versions especially when dealing with web related stuff. In addition, the https://github.com/nlohmann/json lib make json just work.
No one seems to get that the C++ still works and in nearly all cases is faster, compiles very fast and is very quick to develop with now that everyone has shared their code and since functional algos have been added to the stl. This all happens with the memory safety people require since we have shared and unique pointers and Intel's thread building blocks. My fully featured application is 3.7 MB and takes 12-15 MB of ram to run and handles 100k+ requests per second from my laptop. Those stats aren't even that good with the exception of the rps.
If going fully native isn't your game then how about nginx with the plethora of 3rd party modules that are supplied by other developers? Maybe you just really like js? Maybe js isn't the best but you're going to use it anyway because you know it and other people have already written a lot of your code for you? Maybe you just feel like wasting money on more machines instead of one vps instance and a cache-everything cdn?
Who says I need multiple machines? I just said if you're going to design for horizontal scale, then it becomes less of an issue. Also, there's a lot to be said for most of the code available already written. My time is worth far more than paying a couple extra $ a month to run an app on a second server/vps.
I just said that JS isn't so bad, and that language snobbery is worse when it means you're far less productive.
We get that C++ still works, but we also get that unless you can have an iron grip on the team, third party libraries and CI/CD pipeline, someone will definitely write C in C++, or forget about all those 200+ UB cases, and then all is lost.
