I concur. But I don't regret the time spent experimenting. Even negative results are valuable for advancing the state of the art.

It's understandable that you think that I'm a core contributor, but I'm really just an informed community member. I have no vested stake in Rust, and I'm not afraid to criticize the core team when they make baffling decisions (example: the tone-deaf new syntax for fixed-length arrays).

And just because Rust has a focus on pragmatism doesn't mean that it's not blazing new territory. Neither Ada nor Cyclone can boast such extensively useful statically-safe references. And figuring out how to do unboxed closures memory-safely in a language without a garbage collector is, as far as I can tell, entirely novel (though you'd have to ask a PL researcher to be certain). I expect aspects of Rust to show up in all future systems programming languages, including future revisions of C++ (as well as brand-new efforts such as M#).

It is unfortunate that you think Rust is not improving the state of the art: no other language is low-level and memory safe, with the same flexibility as Rust. Rust is certainly pushing the research envelope further than Go, and, anyway, it seems to me that improving on C is something very desirable given the recent spate of horrible bugs in C libraries, caused by memory safety violations (heartbleed etc).

Because we actually have to release something. And you can't be all things to all people. The best we can do is try to create a powerful, safe, extensible language, low overhead language with unsafe escape hatches. The hope is that this will allow for future advances in lightweight, task based concurrency in the form of libraries, as opposed to as baked-in language features.