If you don’t consider Rust to be a systems language, then you’ve got a very skewed perception of what a systems language is.
You seem to be alluding to Rusts ABI potentially being an issue, and that’s a fair criticism. Where a stable ABI needs to be exported, Rust supports the C FFI, like almost all other languages.
For example, while you are advised to put `#[repr(C)]` on types you want to have a known layout for FFI, to the best of my understanding this decoration isn't included for generic types like tuples, slices, or `Vec`. Afaiu, Rust reserves the right to change the layout of `(T1, T2)` for `#[repr(C)]` types `T1` and `T2` on a build-by-build basis, which makes a lot of the core types unsuitable for FFI.
Anyhow, that's my issue with it as a "systems" language. I can't (yet) write code that compiles down to the minimal operations I believe the computer can do, without re-inventing a non-trivial hunk of the standard library. Or, if I can, I can't find the language in the spec that ensures I won't have to fix things.
Isn't std::vector in C++ equally unspecified, though?
> The 2000-foot version: Rust structs, enums, and tuples are now automatically smaller in some cases. It's possible for the compiler to work with types whose in-memory field order doesn't match that of your source code.
This would mean (again, as I understand it) that you cannot rely on the order of elements in a tuple, if for example you wanted to pass a `&[(T1,T2)]` to some other code (even other Rust code, but built separately).
Edit: serious follow up: You've been working with Servo, and I'm assuming at various moments you (pl) need to map in shared libraries that Servo wasn't built with (e.g. codecs, whatever). Do you avoid Rust types in these FFI interfaces, do you rewrap everything, or have pervasive repr(C) type analogues instead?
It might be that I'm the only person in the world trying to do Rust-to-Rust FFI, but it feels like (i) it isn't that far from being really tasteful, but (ii) it has a bunch of issues that make it seem that no one has ever tested it (e.g. default allocators being different, weak guarantees about layout).
I'm suggesting that the exclusion of Rust from that category is wrong. Even with it as narrow as you just defined it, Rust still fits into that category.
Is it the best systems language available at the moment? It depends on your context. With TockOS, if you can use that, I would say it is. With Redox and other full OS impls, it's clearly capable as a systems language. With examples of kernel modules for Linux written in Rust, it's again clear that it can work in that environment. By excluding it from that category, it continues a line of FUD against Rust and in favor of C.
> Yea you could say we resort back to the C FFI whenever i need to think about dynamic linkage
Yeah, this is a bummer. And for the foreseeable This is probably going to be the case (C++ has this same issue, but to less of an extent because it is generally easier to flow between C++ and C).
> jesus is it a tedious process for me.
Yeah, again, where a strong ABI is needed it's a problem, but there are people working on some solutions to make this easier, for example:
C headers to Rust, https://docs.rs/bindgen/0.30.0/bindgen/ C headers from Rust, https://docs.rs/rusty-cheddar/0.3.3/cheddar/
(I'm not sure of the status of the latter, but bindgen is getting a lot of attention right now).