Why Not Rust?
As I've said before, Go has the advantage of mediocrity. It's boring as a language, but it does automatically most of the things you need for web back-end stuff. It's garbage-collected and does subscript checking, so you're covered on memory safety. There are stable libraries for most things you need in a web server, and those are mostly the same libraries Google is using internally, so they're well tested. The green thread/goroutine approach means you don't have the problems which come from "async" and threads in the same program; there's only one concurrent task construct.<p>There's a lot to be said for that. You can put junior programmers on something and they'll probably get it more or less right.<p>Rust is very clever. The borrow checker was a huge step forward. It changed programming. Now, everybody gets ownership semantics.  Any new language that isn't garbage collected will probably have ownership semantics. Before Rust, only theorists discussed ownership semantics much. Ownership was implicit in programs, and not talked about much.<p>Tying locking to ownership seems to have worked in Rust. A big problem with locking has been that languages didn't address which lock covers what data. Java approached that with "synchronized", but that seems to have been a flop. (Why?) Ada had the "rendezvous", a similar idea. Rust seems to have made forward progress in that area.<p>I used to say that the big problems in C are "How big is it?", "Who owns it for deletion purposes?", and "Who locks it?" At last, with Rust we see strong solutions to those problems in wide use.<p>Much work has gone into Rust, and it will have much influence on the design of later languages. We're finding out what happens with that model, what's useful, what's missing, and what's cruft.<p>In the next round of languages, we'll probably have to deal directly with non-shared memory. 
Totally shared memory in multiprocessors is an illusion maintained by elaborate cache interlocking and huge inter-cache bandwidth. That has scaling limits. Future languages will probably have to track which CPUs can access which data. "Thread local" and "immutable" are a start.