Rust is becoming such a huge systems development language, that's so good to hear that finally the developers are getting better deal for performant applications instead of C/C++
It's too early and too immature a language for all the fawning it gets on HN.
I think if the developers do it right they can snag enough mindshare among new developers that Rust will be a serious competitor to C and C++ in 10 years or so. Which is great, because I think it's a better language. But it isn't there yet.
It takes a while.
(I lost interest in Python in early 2000s, and then it got popular. So if I lose interest in Rust it's bound to get popular.)
In particular, what do you turn to for the kinds of things others would use Python for?
I'm definitely keeping an eye on it though, because if it keeps going at the same rate it has the potential to be great in 10 years.
But at the same time, flurries of activity aren't universally positive: it becomes harder to filter out the low-quality contributions that introduce subtle bugs, and smaller/more strict teams have an easier time maintaining stringent quality controls.
PHP and JavaScript very rarely segfault either. Sure, they use virtual machines (PHP's is non-JITed too!); and yes, their CPU and memory usage are comparatively astronomical. But I can only hope that Rust's memory-safety doesn't wind up attracting the same kind of unskilled language architecture "contributions" that PHP has, or wind up with an ecosystem as fragmented as Node's.
Going from "PHP has memory safety" to "memory safety causes the quality of code to decrease" is quite a leap.
Haskell also has memory safety.
Haskell as an excellent example of a language that, by design, filters out probably many well-meaning individuals who don't have the requisite level of high-level skill.
Languages like Java, BASIC, PHP, etc are easy to get started with, which means those languages attract all types. Perl is somewhat in this class too, along with C++ due to that language's widespread popularity.
In PHP's case, the language's lack of inherent default-to-paranoia security settings has bitten it hard, because no real consideration was given to these phenomena (or apparently anything else, but that's a different story).
It's a nuanced (social) issue, but solving the type safety problem does make it generally easier not to shoot your foot when you still don't know what you're doing. The hope is that the programmer steadily advances beyond the baby-steps/worsethanfailure.com stage - and doesn't build any large systems that are too big to rewrite before they're decent.
Languages like Haskell, Lisp/Scheme, Erlang, C, assembly language, etc are generally difficult to do large-scale useful things with unless you've either studied the language a lot and/or already have programming experience.
It depends on which PHP you mean.
http://react-etc.net/entry/php-8-to-ship-with-a-jit-compiler
(My primary dev platform is 32-bit, so I can't take HHVM seriously.)
Memory safety isn't a bad thing. But maybe pushing it as the thing will end up making it harder for newer systems programmers to be comfortable dropping into "unsafe-Rust" when it's necessary out of fear, or harder for them to learn the lessons that C and C++ folks have had to when they do have to use "unsafe-Rust". We just don't know what the impact will be in that regard. It's part of being a young language--it just needs time to develop.
At least that's the theory. Thinking about it, there are probably people out there who can nail things like memory management but are terrible at eg higher-level application architecture to such an extent that they're ultimately not competent engineers anyway. It's possible at least.
I agree that it's hard to find people who do systems programming, but those I know have mostly heard of Rust.
There isn't much else of anything happening in that space aside from C++ iterations.
Rust still needs to improve its compile times and IDE related tooling, to make it appelative to the enterprise coder used to the comfort of Java / .NET tooling + C++ for lower level stuff.