We have and will add language features; though we haven't added any HUGE things in a while. You are right that RFCs contain language changes. A lot of them are small. Some of them are big, and there's certainly more big ones on the horizon.
The most recent one off the top of my head is the ? syntax RFC, which should reduce the amount of error-handling boilerplate.
The big ones though are:
* Specialization. This will allow you to write ultra-performent generic code by special-casing when you have the knowledge. It also will be a building block for the next few features.
* The bag of features colloquially known as "inheritance", though that's not really a good name.
* Non-lexical borrowing, and various other borrowck usability improvements.
* Abstract return types, which will allow for you to remove some allocation and make certain type signatures much better.
* Incremental compilation.
Those are the ones on the short list. There are others too, like higher kinded types.
Great. They all look great. The ones like higher kinded types are the ones that I am highly suspicious of. The typical C programmer who pokes around hardware data sheets and writes drivers and stuff will likely not pay much attention to Rust if such complex features are added.
Also features like that makes me wonder if you folks are really targeting C/System programmers. Sorry if I sound negative, that isn't my intention.
Systems programming does not preclude a language from having a good type system or higher level abstractions.
A good example is Phil's OS. http://os.phil-opp.com/. He's designing an operating system in Rust, and it has surprisingly few "unsafe" parts. The rest of it is made safe using some neat zero-cost abstractions.
Higher kinded types isn't going to happen anytime soon. It's something that crops up often in discussions when people want to model something complicated with the type system; but it's a very nontrivial feature that would probably need to wait for Rust 2.0, if ever. Even if it would exist, you can just not use it. Like most of the other features being added.
> Systems programming does not preclude a language from having a good type system or higher level abstractions.
I didn't say that system programming does not need a good type system. I am also not saying that it is impossible to design operating system software with Rust.
As someone who had been on both the sides of the abstraction and having closely interacted with the system programmers, I think it is just too hard to convince them to use Rust. It is not just about the language alone, it is about what minimum you need to bootstrap a system (among many other things).
Anyway.. good luck to the OP in "rewriting everything in rust" and also getting it to the same quality/feature parity as others in the game and also get others to use it as well.
Yeah, I'm just saying that "higher kinded types" (which, again, Rust isn't getting anytime soon), does not make Rust something that isn't targeting systems programming; in response to "you folks are really targeting C/System programmers".
Many of Rust's designers are experienced systems programmers. A _lot_ of effort goes into making it systems-ready.
> it is about what minimum you need to bootstrap a system
Rust works on any target LLVM compiles to, and you can opt out of the standard library if you're writing baremetal things. There already are people writing low level Rust things.
But yeah, I know the skepticism you refer to; seen it in action before. But in the case of Rust I've rarely seen any concrete points being brought out (aside from perhaps "LLVM doesn't target enough things", which is fair). The language developers do try to take input from everyone and make it more systems ready; but there really isn't much that can be done when there isn't any input other than a strong preference for C.
They are specifically there so that you can write zero-cost abstractions. Yes, people who are hardcore C programmers may not have experience with more advanced type system features, but it's all in service to the goal of writing expressive code that goes as fast and as safely as possible.
As a practical example of higher kinded types, you can't say "this function takes an Rc<T> or an Arc<T>. I just want something refcounted, but I don't care about how." HKT would get you there.
Another common problem it would solve is "I don't want to write both a &T and &mut T version of my function."
