C was standardized in 1989 and in the early 90's it was still easier to port K&R code than ANSI C.
C++ only got standardized in 1998, two years after Java appeared. Each compiler supported different parts of the standard, had vendor specific libraries and suffered from C like APIs.
Java was a good enough C++ that one could expect with would have the same behavior in every system.
Also the Java 1.0 networking libraries were already miles ahead of anything one could find for C and C++, and its SDK was free in the days we paid for compilers.
For Go, you get an opinionated language/build system, decent tooling that is quickly evolving, no higher-kinded types, very systems-oriented API, ability to target multiple platforms without a VM, and also a number of useful frameworks.
In short, and this is just MHO, I would rather build a systems-oriented app with Go than with Java, and I would rather build a webapp with Java than with Go. It's not clear to me that, as a language, Go can capture bizlogic complexity the same way Java could in a webapp. Also, it's definitely clear to me that I would rather deploy a native binary than a vm + bytecode for systems-heavy tasks, like automating maintenance of a database cluster, and Go is excellent for that.
The big thing you're missing compared to the mid-level languages you mention is garbage collection. Rust makes manual memory management much easier than C++, but it's still never going to be quite as easy as the "just make objects and don't worry about it" that you get in a garbage-collected language.
Look at Spring MVC. Both it and Spring in general are reflection machines. This provides a lot of easy work that's relatively safe even with duck typing.
For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.
Nobody wants to code C++ for webservers because of the risk (PayPal not included) but Rust doesn't have that issue.
Up until now, I've only ever used interpreted, dynamic languages for web development. In contrast, Rust offers me a tight memory footprint (no silly things like unicorn-worker-killer), high performance (the average response time for most of my Rails apps is 150ms), and a slew of static guarantees about types (no "undefined method for nil:NilClass") and memory safety. It also has some really cool things like sanitary macros and syntax extensions that have allowed me to build out a fairly simple yet robust ORM similar to ActiveRecord in look and feel.
I may be forcing a square peg into a circle hole; all my current work is experimental.
Can you clarify on the difference between "server development" and "application code"? In this context, I've always considered those terms to be the same.
Edit: I think I understand what you mean by application code — business logic code? Reasonable concerns. I don't have much to say yet (I'm just doing framework stuff now in preparation for real applications), but here's a demo of my aforementioned ORM in action[2].
[2] https://gist.github.com/SkylerLipthay/9015e6c79859e7dc8709
Rust is good for extending Python, Ruby, etc stuff. More safe than C.
Server side you have many more good choices, but Rust does have a nice FFI story in both directions.
Whether you want to write your entire app in Rust is a different question. I'd want to get more experience with Rust before answering that question -- writing a performance sensitive portion in Rust first would go a long way to answering that question.
The fact that Rust requires that you think about memory management made it feel less expressive and less productive. The strictness of the compiler also got in the way of "productivity". There's nothing wrong with that strictness, but in the domain of web-development where productivity and expressiveness is often more valued than raw performance Rust doesn't feel like the optimal tool.
To use Rust for web-development feels like a premature optimization.
I think for web-development, it's probably more productive to use Ruby/Python/etc... and call Rust externally to optimize hot spots.
Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.
Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.
Java and in particular the JVM has a massive ecosystem which ranges from small libraries through to major infrastructure components e.g. databases, big data, enterprise, middleware, integration etc. And the fact that the biggest and best companies are using it means you can leverage some high quality components e.g. Twitter, Netflix, IBM. That said all of the above isn't mandatory for 90% of websites most people build.
As for why Java is popular for web server deployment. Not having to worry about memory management, having a less complex feature set and excellent performance are the key features I can think of.
This is a failure of your imagination. The linked article points out some of the differences, but there are many others. This topic has been endlessly discussed, and I'm kind of sick of repeating it, but I have written several posts on this matter and you can hunt them down if you wish.