Yeah Rust isn't safer than an already memory-safe language (though it might be faster, then again it's also quite a bit more work wrt e.g. Go). but
> Don't write C/C++ in 2015.
That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere.
You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.
> You can't really/easily use a scala library from MRI
You can easily link Scala with Ruby by running both on the JVM. Assuming you really want MRI, on the client-side that implies running 2 processes with their own runtime at least, instead of just one process. There is a reason for why I've heard of Ruby developers choosing JRuby to deploy Ruby apps, because having only one GC for managing a long-running process is expensive enough, having more than one gets awful fast.
On the server-side on the other hand, you have the freedom of deploying your stuff on multiple servers, which is often the case so you can use a micro-services approach - in our current project the front-end is developed in Ruby / Javascript and the backend in Scala, linked through a web service API. The great thing about this, besides using the best tool for the job and so on, is that people can work on them in parallel.
IMHO, I think the reusability of C is overstated. I haven't used C libraries in any of the JVM apps I ever developed and this reduced the headaches I've had back in the days when I did stuff with CPython or Ruby MRI. And given a potent runtime, you can make both Python and Ruby run on top of it with reasonable performance (compared to their reference implementations).
> Don't write C/C++ in 2015.
That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere.
You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.