Could you explain what differences make Go optimized for server software and Rust for systems software/C replacement? I'm not being rhetorical -- I genuinely don't understand and would like to.
Related: Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?
The mandatory garbage collection by default in Go would be a good example of a trade-off they make differently.
A rust programmer must be aware of the complexity of memory management. Although they are not forced to use all of it it, the standard library does expose enough of it, to force every rust programmer to be comfortable with the complexity of it.
In return they get the opportunity to write code that can compete with c/c++ in terms of performance, and control over latency, while still retaining safety.
>Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?
Depends on how much you care about maturity and what timescale the code has to run in production.
Rust code will be much faster than equivalent Ruby/Python code, but the memory management of it, will be more complicated. I would argue Go offers a better trade-off in performance, complexity and maturity for those types of projects, even though Rust is a much more interesting language.
So, if you can afford to not micro optimize your allocation strategies and just use a garbage collector, i would always choose to do so. Even with a language design as pretty as that of Rust.
It's not mature enough to be a contender for Ruby/Rails or Python/Django yet, but assuming it gets there, it may offer incredible performance.
Teepee (a Rust HTTP library under development) put together a page that explains the current state of affairs: http://arewewebyet.com/
I think some people refer to "Systems language" as a language you would write services and back-end code in, like Java, rather than than a language you would use to write a kernel driver or a render engine, like C.
