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.
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.
Nobody wants to code C++ for webservers because of the risk (PayPal not included) but Rust doesn't have that issue.
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.
They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'. Never heard a "why we moved from Java to Go story", heard plenty of infrastructure rewriting from ruby/python/nodejs to Go. People stuck in enterprise Java/C# ain't going to move a 10-15 yo infrastructure to the latest hype,they'll stick to the JVM or the CLR which offers plenty of choice already.
These (former) devs might have used Rust instead of Go though Rust doesn't come with a big webapp related ecosystem yet (it will).
In this space (compile to executable - statically typed yet still expressive languages without manual memory management) there are basically 4/5 languages in competition : Go, Rust, Nim, D and Crystal. One of them will be the 'C++ for suckers of the next 10 years' and will be incredibly successful as the demand is quite high. So Go is definitely in competition with others in that space.
Now let's the competition begin.
Rust is definitely not generally used by people who would otherwise use a scripting langauge.
There are dozens of languages with the same target audience as Go (with a similar or better maturity level); there are very few languages with the same target audience as Rust (suitable for embedded systems sans libc) with the maturity of Rust.
I fail to see why pythonists or rubyist couldn't use Rust. On the contrary Rust has more semantics that are closer to these languages than Go has.
Uh... goodness gracious no. Going from Python to Go is a bit of a learning experience, and you might lose some features you're used to while gaining some new ones you're not very used to, but it's not too big a deal. Going from Python to Rust is halfway as hard as going from Python to Haskell. Radically different philosophies, radically different semantics (GC to no GC is shocking enough, but Rust takes "no GC" to new heights of foreignness).
The first program a Pythonista writes in Go will pretty much work. The first program a Pythonista writes in Rust will explode into a half-page compiler error discussing concepts they've never heard of before.
None of this is a criticism of Rust... I applaud Rust for getting itself a good distance away from Python! In 40 years I think "imperative languages with no built-in ownership concepts" will be regarded in much the same way we regard line numbers today... "How did you ever use that? Are you serious? Who would ever think that was a good idea?" (Well, you had to be there...) But in the meantime, it's no contest... Go is way closer to Python than Rust is, and yeah, to some extent I personally consider that a criticism of Go. (I like Go for work, but to some extent I see it as a last-generation final refinement of its ideas, whereas Rust is a one of the first usable languages of the next generation. Both have their place. I suppose that doubles as my own explanation of why they aren't competitors, or at least, not direct competitors.)
Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).