Agreed. At this point Rust is already looking rusty. A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool.
As someone who works with Rust on a daily basis to implement a browser engine, I can confidently say that Rust is not a solution in search of a problem for our domain. As an example, I implemented CSS "letter-spacing" the other day, and it worked first try after compiling. The layout code I write has a remarkable resilience to crashes; in the rare cases that it panics, it aborts safely. And I get parallelism "for free" as I implement more layout features, because the compiler stops me if I'm about to do something non-thread-safe. None of this applies to C or C++, and the end result is that we can move faster and write cleaner code.
Either he has a need to a "better/safer etc" C, or he doesn't. If he doesn't, then Rust isn't for him.
And it's not like anybody tries to market Rust to people who don't need it ("so we're told").
Since the agent runs inside of a Ruby program, our only good choices are Ruby itself or a language without a garbage collector (embedding a language with a GC inside a language with GC is asking for trouble -- take a look at the bug tracker for TheRubyRacer for some color). Our initial version of the agent was written in Ruby, but carefully controlling memory usage or performance in Ruby isn't really feasible.
We prototyped a new version of the agent in C++, but I personally didn't feel comfortable shipping a binary that would run in thousands of customers' Rails apps in a language that could segfault if you're not careful. We took Rust very seriously last November, even thought it was still very young, because it gave us a language with direct control over memory with compiler-verified guarantees that our program wouldn't segfault.
TLDR: Rust is a very good choice for writing performance or memory-critical code that will be embedded in a high-level-language.
Also, because it offers compile-time guarantees about safety, I expect it to expand the number of cases where people feel justified in embedding a low-level language for performance-critical problems.
C programs doing what I'm doing have traditionally had security issues. Since our code often runs in privileged locations, that's an unacceptable risk. Plus, Rust is vastly more expressive than C and not messed up like C++. And abstractions are cheaper, too. For instance, we use Generics + Traits as a way to keep flexibility and a plugin model per frame, while keeping the performance of static dispatch. C wouldn't be able to do that in an easy way.
When you mention you are a C programmer or like coding in C, they begin to blabber about C being legacy, Rust this, and Go that (languages they think are more like Python). All in an effort to cope with the insecure feelings they have because the C programming language and C++ (read: pointers) intimidate them.
I loathe C++, think it's way too dangerous, and C is obviously dangerous. I really want something safer to do systems programming in, that's successful (pretty much every prior alternative has failed in one way or another). Maybe Rust will be that.
I take it you haven't programmed in C11 or C++11? Modern C exists and C is too ubiquitous to be replaced.
I'm all for new projects and new languages but I just don't understand the hype around Go and Rust as a C replacement.
C99 and C11 add a variety of nice things, but they don't make the language markedly safer.
How long have you spent tracking down wild pointer and using freed memory errors? Every have to convince your boss to spend $$$ on a hardware debugger to find one? (ATRON, back in the 8088 days.) Or look at Mozilla's very real world motivation for this project.
You have to know pointers and manual memory management to program in Rust. Rust isn't there to save you from having to learn about pointers. Rust is instead a reaction to the empirically observed fact that nobody [1] has ever written a multi-million-line program with a large team in C or C++ without accidentally making dangerous memory-management-related mistakes, and "just program better" is an approach that has been tried, and failed, again and again and again.
[1]: OK, maybe the Mars rover and the like are counterexamples, but the extreme amount of verification required means that this approach is far too costly to be practical for most software development.
Rust will replace C in some new development that would have been done in C had Rust not existed, and some existing projects may switch from C to Rust (presumably, by components, rather than as big bang conversions.)
But, sure, its not like C will disappear just because Rust 1.0 exists. But it's not like anyone, ever has argued that to be the case.
Wanna say something stupid? Do it with your real nickname.
I think Rust is awesome.