As a die-hard C guy, Rust is the first "new systems programming language" since Cyclone and D that I didn't immediately dislike. A lot of really interesting ideas in here. I'd love to know what Mozilla uses this for internally.
That said, it's hard to imagine anything displacing C for me. Almost any systems code I write these days is something I'll eventually want to be able to expose to a high-level language (Lua, Python, Ruby, etc). To do that you need code that can integrate into another language's runtime, no matter what memory management or concurrency model it uses. When you're trying to do that, having lots of rich concepts and semantics in your systems language (closures, concurrency primitives, garbage collection) just gets in the way, because you have to find out how to map between the two. C's lack of features is actually a strength in this regard.
I do really like Rust's expressiveness though. The pattern matching is particularly nice, and that is an example of a features that wouldn't "get in the way" if you're trying to bind to higher-level languages.
I've only recently started to look at D as a number-crunching language, but it certainly sounds like you know a bit more than me here.
Let me ask you a question or two: is there anything at all that makes it possible to interface D with Python? I'm aware of PyD [1] but it looks like it only worked with D1.
If I wanted to stick with D and Python, would it be the case that I'd have to (re-)write something like PyD from scratch, or is there a simpler approach?
A bit of Mozilla commentary: There is no "internally", really -- it's an open organization. So you can find out!
The answer, unhelpfully, is that so far the only significant rust program is its own compiler.
There's people who want to experiment with writing new browser stuff in it. Not sure how serious that is, and I bet it's pretty far off before you see Firefox shipping with Rust code.
I dislike duck typing; I much prefer to have an explicit declaration of what interfaces you are implementing. I also think the type system is too dynamic for a systems language (eg. their answer to generics requires run-time type checking for every operation).
Also, just as a gut-level reaction I didn't feel excited about any of the expressiveness that Go offers (compared with my reaction to Rust's pattern matching, which to me is a clear improvement over how you'd express an equivalent thing in C or C++).
I must have misinterpreted the intent of this from "Go for C++ Programmers":
> Because the conversion is dynamic, it may be used to implement generic programming similar to templates in C++. This is done by manipulating values of the minimal interface.
I thought they were saying this was their answer to generic programming, but it appears this is not the case. In any case, it was just an example of my general feeling that the type system is more dynamic than I prefer for systems languages.
I particularly like the natives and testing support, but I agree with what you said; I wish there was a way (maybe there is and I just haven't figured it out yet) to do a reverse native thing; that is, create a C wrapper around a rust library (and then yes, use SWIG to generate a python / ruby / etc. binding for the rust library).
I think your approach is wrong all together - D actually allows you not to use 2 different languages in your project, specifically one high level and another one low level. The whole idea is that language is flexible enough, that it allows you to both write performance critical and high level code when you need to. That saves you all the troubles of interfacing, different runtimes and so on.
But my project is a library whose functionality I want to expose to any language that cares to write wrappers for it. Reimplementing libraries in every language is a waste of effort and will have worse performance than sharing a single C library across many languages.
That said, it's hard to imagine anything displacing C for me. Almost any systems code I write these days is something I'll eventually want to be able to expose to a high-level language (Lua, Python, Ruby, etc). To do that you need code that can integrate into another language's runtime, no matter what memory management or concurrency model it uses. When you're trying to do that, having lots of rich concepts and semantics in your systems language (closures, concurrency primitives, garbage collection) just gets in the way, because you have to find out how to map between the two. C's lack of features is actually a strength in this regard.
I do really like Rust's expressiveness though. The pattern matching is particularly nice, and that is an example of a features that wouldn't "get in the way" if you're trying to bind to higher-level languages.